DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-17 have been submitted for examination and are pending further prosecution by the United States Patent & Trademark Office.
Allowable Subject Matter
Claims 7 and 11 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Specification
The abstract of the disclosure is objected for the following reason(s):
It refers to the purported merits of the invention
Applicant is reminded of the proper language and format for an abstract of the disclosure.
A patent abstract is a concise statement of the technical disclosure of the patent and should include that which is new in the art to which the invention pertains. The abstract should not refer to purported merits or speculative applications of the invention and should not compare the invention with the prior art.
The abstract should be in narrative form and generally limited to a single paragraph on a separate sheet within the range of 50 to 150 words. It is important that the abstract not exceed 150 words in length since the space provided for the abstract on the computer tape used by the printer is limited. The form and legal phraseology often used in patent claims, such as "means" and "said," should be avoided. The abstract should describe the disclosure sufficiently to assist readers in deciding whether there is a need for consulting the full patent text for details.
The language should be clear and concise and should not repeat information given in the title. It should avoid using phrases which can be implied, such as, "The disclosure concerns," "The disclosure defined by this invention," "The disclosure describes," etc.
When re-submitted, the new abstract must be in a separate sheet, apart from other sheets.
Correction is required. See MPEP § 608.01(b).
Drawings
The drawings are objected to because FIG. 1 contains various elements whose names and/or reference numbers are missing one or more characters: "ab 102", "Custom Test/Use Device(s) 110", "Ne 1", and "Test Managem nt System 103". Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Claim Objections
The following claims are objected to because of antecedence issues. It is suggested Applicants amend these claims as follows:
Claim 1
-- defining a device integration package (DIP) that enables communication between a [[the]] test automation system and a [[the]] plurality of devices, the DIP including: --
Claim 16
-- define a device integration package (DIP) that enables communication between a [[the]] test automation system and a [[the]] plurality of devices, the DIP including: --
Claim 17
-- define a device integration package (DIP) that enables communication between a [[the]] test automation system and a [[the]] plurality of devices, the DIP including: --
Claims 2-15 are additionally objected to due to their dependence on objected parent claim(s).
Appropriate correction is required.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 5, 8, 16 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over US 20240193057 A1 - hereinafter "Bar-Niv", in view of WO 2019094029 A1 - hereinafter "Yim", and in view of WO 03058484 A1 - hereinafter "Joiner".
With respect to claim 1, Bar-Niv teaches,
A computer implemented method for device testing and management, the computer implemented method comprising:
defining a device integration package (DIP) that enables communication between a [[the]] test automation system and a [[the]] plurality of devices, the DIP including: - "Digital key test manager device 110 (test automation system) may use standard test APIs (DIP) to allow for a unified testing system. Digital key test manager device 110 may use a common set of tests 260 to test a variety of devices under test and computing devices that implement the standard APIs." [0045]
a set of APIs that define a technical interface between the test automation system and the plurality of devices, the set of APIs being device-agnostic and configured to establish communication with the plurality of devices; and - "Digital key test manager device 110 may test a combination of any digital key (DK) enabled devices, such as computing device 102 (e.g., mobile phone or wearable device), and any device under test, such as device under test 112 (e.g., equivalent test devices\benches\
simulations or actual vehicle) using a common set of digital device and vehicle test APIs, discussed below with respect to FIG. 1F." [0028] "Vehicle test API 182 forms a standard interface to interconnect with device under test 112. A variety of devices under test, such as simulations, test benches, and production vehicles from multiple manufacturers, may implement the vehicle test API 182 and thus help enable the standardized testing environment." [0052]
a configuration specification that defines how the test automation system interacts with each of the plurality of devices using the set of APIs; - "FIG. 1D is a conceptual diagram illustrating a digital key test manager device (test automation system) with testing extensions, in accordance with one or more techniques of this disclosure. System tests 142 (configuration specification) may be a system test plan through the standardized APIs." [0042]
Bar-Niv teaches does not explicitly teach the following limitations which, in the analogous field of test execution, are taught by Yim:
providing - "A host computing device is provided for testing devices under test (DUTs) using a test suite that includes first and second tests." (Abstract) "Test agent 460 can include target-side software executing on a DUT, e.g., DUT 110a, for relaying commands, test results, and/or other communications between test runner 440 and one or more HAL drivers, including HAL driver 462." [0075]; Fig. 4
establishing communication between a backend system and the plurality of devices using the DIP; - "Host computing device 340 (backend system) and TISS 160 can provide robust and reliable testing of DUTs with one or more HALs, as well as APIs (DIP) for a test developer to interact with one or more target HALs and other aspects on a target device such as DUT 110a to reduce (or eliminate) developer effort regarding loading and communication of tests and related images." [0088]
distributing test jobs across the plurality of devices using a job scheduler; - "Testing commands can include one or more commands to execute one or more tests, test modules, and/or test suites one or more DUTs of target system 310." [0064] "Test runner 440 (job scheduler) can include host-side software executing on host computing device 340 that can process test logic and communicate with one or more target-side test components (e.g., DUT 110a) to send testing commands 450 to the target-side test component(s) and get test results 452 from the target-side test component(s)." [0074]
receiving, at the backend system, test results collected by the software agent; - "Host computing device 340 (backend system) and target system 310 can communicate using testing messaging 350, as mentioned above. In the example of testing system 400, testing messaging 350 includes: testing commands 450 sent from test runner 440 executing on host computing device 340 to test agent 460 executing on DUT 110a; test results 452 sent from test agent 460 to test runner 440;" [0077]; Fig. 4. "At block 1830, the host computing device can receive first test results for a failing first test executed by the first DUT, such as discussed above at least in the context of FIGS. 7-16." [0224]
processing and aggregating, at the backend system, the test results in real-time; and - "At block 1830, the host computing device can receive first test results for a failing first test executed by the first DUT, such as discussed above at least in the context of FIGS. 7-16." [0224] At block 1840, the host computing device can determine, based on the first test results and based on the first DUT sharing the common design with the second DUT, to execute the second test before the first test on the second DUT, such as discussed above at least in the context of FIGS. 7-16." [0225]
providing, for display on a user device, the test results. - "Testing entity computing devices 410 can include one or more computing devices that include and/or store test results 412, test coordinator / user interface 414, one or more software images 416, and test monitor 418." [0068] "Test coordinator / user interface 414 can also include software and/or hardware for displaying test results," [0069]
It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement Bar-Niv with Yim's teachings because doing so would provide Bar-Niv's system with the ability to accelerate and facilitate device approval, as suggested by Yim [0026].
Bar-Niv does not explicitly teach providing a cross-platform software agent to each of the plurality of devices;
However, in the analogous field of software agents, Joiner teaches,
"A system and associated method and computer program product are provided for analyzing a network. Included is a plurality of agents coupled to a plurality of computers interconnected via a network. Each agent is adapted to collect information relating to at least one of the computers." (Abstract)
"In the context of the present description, an agent 900 may refer to any computer program, hardware, etc. that is capable of collecting network traffic information involving a computer on which it is installed or associated." (page 10, last paragraph through page 11 first paragraph)
"The agent may, however, support multiple operating systems. The agent 900 may be deployed in heterogeneous OS environments and supports a full range of OS's when fully deployed." (page 33, paragraph 5)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement Bar-Niv and Yim with Joiner's teachings because doing so would provide Bar-Niv/Yim's system with the ability to provide cross-platform software agents, as suggested by Joiner (page 33, paragraph 5).
With respect to claim 5, Bar-Niv does not explicitly teach,
grouping the plurality of devices based on one or more technical criteria using device pooling techniques.
However, in the analogous field of test execution, Yim teaches:
"Each test cluster in scenario 800 includes DUTs that share a common hardware design; that is, test clusters 814, 834, 854a, 854a includes DUTs that have respective designs DES 810, DES 830, DES 850, DES 851." [0126]
It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement Bar-Niv with Yim's teachings because doing so would provide Bar-Niv's system with the ability to accelerate and facilitate device approval, as suggested by Yim [0026].
With respect to claim 8, Bar-Niv does not explicitly teach,
wherein the software agent is operable to be executed on a plurality of different operating systems.
However, in the analogous field of software agents, Joiner teaches,
"A system and associated method and computer program product are provided for analyzing a network. Included is a plurality of agents coupled to a plurality of computers interconnected via a network. Each agent is adapted to collect information relating to at least one of the computers." (Abstract)
"In the context of the present description, an agent 900 may refer to any computer program, hardware, etc. that is capable of collecting network traffic information involving a computer on which it is installed or associated." (page 10, last paragraph through page 11 first paragraph)
"The agent may, however, support multiple operating systems. The agent 900 may be deployed in heterogeneous OS environments and supports a full range of OS's when fully deployed." (page 33, paragraph 5)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement Bar-Niv and Yim with Joiner's teachings because doing so would provide Bar-Niv/Yim's system with the ability to provide cross-platform software agents, as suggested by Joiner (page 33, paragraph 5).
With respect to claim 16, Bar-Niv teaches,
A computing system for device testing and management, the computing system comprising: - Figs 1A, 2 and 3
at least one computing processor; and - Figs 1A, 2 and 3
memory comprising instructions that, when executed by the at least one computing processor, enable the computing system to: - Figs 1A, 2 and 3
The remaining limitations are rejected using the mapping from analogous claim 1.
With respect to claim 17, Bar-Niv teaches,
A non-transitory computer readable medium comprising instructions that when executed by a processor enable the processor to: - Figs 1A, 2 and 3
The remaining limitations are rejected using the mapping from analogous claim 1.
Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over Bar-Niv, Yim and Joiner, and in view of US 20190312801 A1 - hereinafter "Kandula".
With respect to claim 2, Bar-Niv does not explicitly teach,
wherein the software agent is operable to: execute test jobs on each of the plurality of devices; and collect test results.
However, in the analogous field of test execution, Yim teaches:
"Testing commands 450 can be sent from test runner 440 to instruct test agent 460 to execute one or more tests; e.g., one or more tests of test cases 442 and/or test cases 464. In response to testing commands 450, test agent 460 can send test results 452 to test runner 440 with some or all of the results of tests commanded for execution by testing commands 450." [0078]
It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement Bar-Niv with Yim's teachings because doing so would provide Bar-Niv's system with the ability to accelerate and facilitate device approval, as suggested by Yim [0026].
Bar-Niv also does not explicitly teach wherein the software agent is operable to: monitor a status of each of the plurality of devices; and collect performance metrics from each of the plurality of devices.
However, in the analogous field of performance evaluation, Kandula teaches:
"In client-server environments, a server may communicate with multiple clients, with each client having an agent to collect performance metrics from underlying OS and/or services on the client and report the data to the server for storage and analysis." [0010]
"Examples described herein may provide monitoring agents 306A-N and associated top process plugins 308A-N on client-side to optimize and then transmit the optimized performance data to management node 312 (i.e., a server)." [0040]
It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement Bar-Niv, Yim and Joiner with Kandula's teachings because doing so would provide Bar-Niv/Yim/Joiner's system with the ability to optimize the collection of performance data, as suggested by Kandula (Abstract).
Claims 3, 4, 9 and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Bar-Niv, Yim and Joiner, and in view of US 7334162 B1 - hereinafter "Vakrat".
With respect to claim 3, Bar-Niv does not explicitly teach,
wherein the job scheduler is operable to optimize allocation of the test jobs to the plurality of devices based on one or more technical criteria.
However, in the analogous field of test scheduling, Vakrat teaches:
"The server dynamically distributes the test programs to a changing population of the computing devices, optimizing the distribution so as to minimize the time to complete the suite." (Abstract)
"Embodiments of the present invention provide methods and systems for parallel testing of multiple low-end computing devices, such as mobile information devices in which different tests in a test suite are dynamically allocated to different instances of a computing device-under-test." (col. 2:49-53)
"This mechanism enables the server to dynamically distribute different elements of a test suite to the different instances of the computing devices-under-test, and to balance and track the load of testing among an arbitrarily large number of client devices." (col. 2:63-67)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement Bar-Niv, Yim and Joiner with Vakrat's teachings because doing so would provide Bar-Niv/Yim/Joiner's system with the ability to minimize the time needed to complete execution of a suite of test programs, as suggested by Vakrat (Abstract).
With respect to claim 4, Bar-Niv does not explicitly teach,
dynamically adjusting the allocation of the test jobs based on real-time monitoring of the status of the test jobs and the plurality of devices.
However, in the analogous field of test scheduling, Vakrat teaches:
"The server dynamically distributes the test programs to a changing population of the computing devices, optimizing the distribution so as to minimize the time to complete the suite." (Abstract)
"Embodiments of the present invention provide methods and systems for parallel testing of multiple low-end computing devices, such as mobile information devices in which different tests in a test suite are dynamically allocated to different instances of a computing device-under-test." (col. 2:49-53)
"This mechanism enables the server to dynamically distribute different elements of a test suite to the different instances of the computing devices-under-test, and to balance and track the load of testing among an arbitrarily large number of client devices." (col. 2:63-67)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement Bar-Niv, Yim and Joiner with Vakrat's teachings because doing so would provide Bar-Niv/Yim/Joiner's system with the ability to minimize the time needed to complete execution of a suite of test programs, as suggested by Vakrat (Abstract).
With respect to claim 9, Bar-Niv does not explicitly teach,
wherein distributing test jobs across the plurality of devices using the job scheduler comprises optimizing allocation of the test jobs to the plurality of devices based on one or more of: ...network connectivity of each of the plurality of devices.
However, in the analogous field of test scheduling, Vakrat teaches:
"Assignment of the tests to be performed in the JAD file takes into consideration the number of clients connected to the test framework 40 in order to equitably distribute the test load among all the clients upon request." (col. 10:7-10)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement Bar-Niv, Yim and Joiner with Vakrat's teachings because doing so would provide Bar-Niv/Yim/Joiner's system with the ability to minimize the time needed to complete execution of a suite of test programs, as suggested by Vakrat (Abstract).
With respect to claim 10, Bar-Niv does not explicitly teach,
wherein distributing test jobs across the plurality of devices using the job scheduler comprises dynamically adjusting allocation of the test jobs based on one or more of: ...real-time status of the test jobs;
However, in the analogous field of test scheduling, Vakrat teaches:
"The server dynamically distributes the test programs to a changing population of the computing devices, optimizing the distribution so as to minimize the time to complete the suite." (Abstract)
"Embodiments of the present invention provide methods and systems for parallel testing of multiple low-end computing devices, such as mobile information devices in which different tests in a test suite are dynamically allocated to different instances of a computing device-under-test." (col. 2:49-53)
"This mechanism enables the server to dynamically distribute different elements of a test suite to the different instances of the computing devices-under-test, and to balance and track the load of testing among an arbitrarily large number of client devices." (col. 2:63-67)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement Bar-Niv, Yim and Joiner with Vakrat's teachings because doing so would provide Bar-Niv/Yim/Joiner's system with the ability to minimize the time needed to complete execution of a suite of test programs, as suggested by Vakrat (Abstract).
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Bar-Niv, Yim and Joiner, and in view of US 20150269496 A1 - hereinafter "Arguelles".
With respect to claim 6, Bar-Niv does not explicitly teach,
wherein the device pooling techniques comprise: automatically discover and configure the plurality of devices; and monitor the status and availability of the plurality of devices in real-time.
However, in the analogous field of performance evaluation, Arguelles teaches:
"Using the systems and methods described herein, intelligent and automated tuning of a service may be performed to determine an optimal configuration on test computers before the optimal configuration is put into production." [0013]
"In one embodiment, the automated configuration tuning system 100 may automatically detect the configurable parameters of a service along with the current parameter values and the range of potential parameter values (i.e., the maximum and minimum values). The values of the parameters in the test configurations may then be assigned within the appropriate range. To implement this auto-discovery functionality, the automated configuration tuning system 100 may include an administrative application programming interface (API) to modify the configurable parameters." [0035]
"A plurality of production computers are automatically configured with the optimal configuration if the performance of the additional test computers is improved with the optimal configuration." (Abstract)
"The baseline load tests may use the test loads generated in 205. In another embodiment, the baseline performance may be determined by monitoring the real-world performance of production hosts processing production transactions." [0023]
It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement Bar-Niv, Yim and Joiner with Arguelles' teachings because doing so would provide Bar-Niv/Yim/Joiner's system with the ability to provide efficient techniques for tuning services, as suggested by Arguelles [0004].
Claims 12 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Bar-Niv, Yim and Joiner, and in view of US 10353804 B1 - "Kandru".
With respect to claim 12, Bar-Niv does not explicitly teach,
wherein providing the test results and/or performance metrics comprises generating interactive reports and visualizations based on the test results and performance metrics collected from the plurality of devices, the reports and visualizations being updated in real-time as new data is processed and aggregated by the backend system.
However, in the analogous field of test execution, Kandru teaches:
"During execution of a test run, at step 308 the test results 330 are collected. In one aspect, during testing the results are analyzed at step 310, and metrics are dynamically calculated during the run. In one embodiment, tests may be terminated in response to a threshold being satisfied, where the threshold may be a key performance indicator threshold, for example, an error rate threshold or delay time exceeded. During and following test, the data is analyzed, and metrics are dynamically updated at the GUI to enable a developer to control the continuation of testing in response to ongoing observation of response behavior of the SUT." (col. 6:24-34; Fig. 8)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement Bar-Niv, Yim and Joiner with Kandru's teachings because doing so would provide Bar-Niv/Yim/Joiner's system with the ability to enable developers to more easily identify system issues, as suggested by Kandru (Abstract).
With respect to claim 13, Bar-Niv does not explicitly teach,
wherein processing and aggregating the test results and/or performance metrics comprises analyzing the test results and performance metrics in real-time to detect anomalies and identify potential issues with the plurality of devices and/or the test jobs.
However, in the analogous field of test execution, Kandru teaches:
"During execution of a test run, at step 308 the test results 330 are collected. In one aspect, during testing the results are analyzed at step 310, and metrics are dynamically calculated during the run. In one embodiment, tests may be terminated in response to a threshold being satisfied, where the threshold may be a key performance indicator threshold, for example, an error rate threshold or delay time exceeded. During and following test, the data is analyzed, and metrics are dynamically updated at the GUI to enable a developer to control the continuation of testing in response to ongoing observation of response behavior of the SUT." (col. 6:24-34; Fig. 8)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement Bar-Niv, Yim and Joiner with Kandru's teachings because doing so would provide Bar-Niv/Yim/Joiner's system with the ability to enable developers to more easily identify system issues, as suggested by Kandru (Abstract).
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Bar-Niv, Yim and Joiner, and in view of US 20070033441 A1 - hereinafter "Sathe".
With respect to claim 14, Bar-Niv does not explicitly teach,
wherein establishing communication comprises establishing communication between a backend system and the software agent via at least one of...HyperText Transfer Protocol (HTTP) protocol.
However, in the analogous field of test execution, Sathe teaches:
"In another embodiment, dynamically generated data are shared or transferred between or among agents using dynamic data content servers that employ open communication standards or protocols, such as HTTP or HTTPS." [0014]
"The WQM also allows placing such `tests` on remote computers processors (such as those of test probes 16, 18) under the control of other programs called `Agents` that run tests similar to these on a regular interval to create `performance charts` for each SUT." [0059]
It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement Bar-Niv, Yim and Joiner with Sathe's teachings because doing so would provide Bar-Niv/Yim/Joiner's system with the ability to ensure the security of communications, as suggested by Sathe [0159].
Claim 15 is rejected under 35 U.S.C. 103 as being unpatentable over Bar-Niv, Yim and Joiner, and in view of US 7016800 B1 - hereinafter "Nguyen".
With respect to claim 15, Bar-Niv does not explicitly teach,
wherein establishing communication comprises establishing communication between the software agent and a target device via the DIP.
However, in the analogous field of testing, Nguyen teaches:
"An API console module is used on a console system to forward requests and accept responses from an API agent daemon that resides on the system under test. " (col. 3:51-54)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement Bar-Niv, Yim and Joiner with Nguyen's teachings because doing so would provide Bar-Niv/Yim/Joiner's system with the ability to provide for device-agnostic testing, as suggested by Nguyen (col. 2:49-53).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. WO 2024196977 A1 discloses an automated video game testing framework for executing platform-agnostic test scripts in conjunction with API and agent technology for testing a video game across different gaming platforms. The NPL document "InterOpT: A new testing platform based on oneM2M standards for IoT systems" discusses the development of a test platform to test the IoT solutions developed by different companies according to oneM2M standards.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GEOFFREY R ST LEGER whose telephone number is (571)270-7720. The examiner can normally be reached M-F (IFP) ~9:00-5:00 pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Hyung S Sough can be reached at 571-272-6799. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/GEOFFREY R ST LEGER/Primary Examiner, Art Unit 2192
Prosecution Insights