DETAILED ACTION
This office action is in response to claims filed 28 August 2023.
Claims 1-20 are pending.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1, 3-4, 7, 11, 13-14, 17, and 20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by KNIGHT Pub. No.: US 2012/0246506 A1 (hereafter KNIGHT).
Regarding claim 1, KNIGHT teaches:
An energy management system, comprising:
one or more memory devices storing instructions thereon, that, when executed by one or more processors ([0043] Embodiments may be implemented in code and may be stored on a storage medium (i.e., “memory devices”) having stored thereon instructions which can be used to program a system (i.e., “processor”) to perform the instructions. The storage medium may include, but is not limited to, any type of non-transitory storage medium), cause the one or more processors to:
receive a file comprising a plurality of data points ([0013] Embodiments provide for collection of certain power state information (i.e., “data points”) at a power state transition, e.g., as implemented by an OS. [0034] Thus at this time, desired power state information has been obtained and can be further processed to enable its analysis by a user or other entity such as an analysis tool of a system (i.e., power management system receives an indication (i.e., “file”) of desired power state information representing a “plurality of data points”)) of an energy management device coupled to the one or more processors ([0029] A processor may be controlled to perform power management on a per core basis (i.e., processor cores, representing “processors” are coupled to a “power management” processor device)) through an interface ([0039] The various cores may be coupled via an interconnect 415 (i.e., “interface”) to an uncore 420 that includes various components);
generate a driver ([0024] Method 10, which can be implemented in a performance analyzer, and more particularly in a power profiler of the analyzer, may begin by initializing a device driver of the power profiler (block 20)) based on the plurality of data points of the file ([0017] In one embodiment, a device driver can be used to collect power profile information (i.e., device driver is initialized in order to collect the desired power state information, and is therefore initialized “based on” the desired power state information)); and
execute the driver to read at least one of the plurality of data points ([0031] For each possible sleep state available in the processor (as determined at diamond 130), a loop is traversed that includes reading the corresponding residency counter for that low power state (block 140), which may be realized via reading a MSR for the low power state, and writing the counter value to the entry in the buffer (block 150) (i.e., residency counter data is read for a low-power state in order to collect the power profile information)) or write to at least one of the plurality of data points via the interface ([0032] The collected data can be returned to user-level code that controls the collections and is saved by the user-level code to a file. In other words, the driver does not actually write to a file, instead it passes the buffers to user-level code and the user-level code writes the data to a file during a collection (i.e., execution of the initialized device driver causes user-level code to write desired power state information to a storage)).
Regarding claim 3, KNIGHT further teaches:
the instructions cause the one or more processors to: generate a namespace, the namespace comprising a plurality of predefined variables ([0034] As shown in FIG. 5, method 250 may begin by processing data file 220 (block 260). In one embodiment, this processing may include associating the data with a description of what caused the processor to transition back to an active state (e.g., a timer or an interrupt or even a description of the source code call stack that led to the event that caused the transition back to an active state). At this time the data is thus in a format to be handled, e.g., by a utility of the power profiler (i.e., associating collected data with a predefined description represents generating an indication of a “predefined variable”, and formatted data represents a collection, or “namespace” of data));
compare a name of a data point of a plurality of data points of the file to a plurality of names of the plurality of predefined variables; determine, based on the comparison, a match between the name of the data point and a name of a predefined variable of the plurality of predefined variables; generate, based on the match, the driver to map the data point of the plurality of data points to an instance of the predefined variable ([0031] For each possible sleep state available in the processor (as determined at diamond 130), a loop is traversed that includes reading the corresponding residency counter for that low power state (block 140), which may be realized via reading a MSR for the low power state, and writing the counter value to the entry in the buffer (block 150) (i.e., for each loop it is determined for each sleep state, the residency counter having a sleep state that matches the given sleep state, and writing the residency counter into the buffer corresponding to the sleep state to “map” the residency counter value data point to that sleep state));
Regarding claim 4, KNIGHT further teaches:
the instructions cause the one or more processors to: generate the driver to map between the plurality of data points to a plurality of variables, wherein at least variable of the plurality of variables is an object defined based on a class; wherein the class defines a plurality of attributes for the object that describe the data point ([0034] As shown in FIG. 5, method 250 may begin by processing data file 220 (block 260). In one embodiment, this processing may include associating the data with a description of what caused the processor to transition back to an active state (e.g., a timer or an interrupt or even a description of the source code call stack that led to the event that caused the transition back to an active state). At this time the data is thus in a format to be handled, e.g., by a utility of the power profile (i.e., generation of device driver causes data to be associated with matching descriptions, or “definitions of attributes” that describe the data)).
Regarding claim 7, KNIGHT further teaches:
the instructions cause the one or more processors to: receive the file, the file comprising an indication that a first data point of the plurality of data points and a second data point of the plurality of data points are part of a block; generate, based on the indication that the first data point and the second data point are part of the block, a plurality of variables comprising: a first variable, wherein the first variable is a first object defined based on a first class, the first class defining a plurality of first attributes for the first object, the plurality of first attributes comprising a block identifier of the block; and a second variable, wherein the second variable is a second object defined based on the first class or a second class, the first class or the second class defining a plurality of second attributes for the second object, the plurality of second attributes comprising the block identifier of the block ([0031] For each possible sleep state available in the processor (as determined at diamond 130), a loop is traversed that includes reading the corresponding residency counter for that low power state (block 140), which may be realized via reading a MSR for the low power state, and writing the counter value to the entry in the buffer (block 150). When all such counters have been read for available low power states, method 100 may conclude (i.e., system collects a plurality of residency counter “variables” belonging to different groups, or “classes” of variables defined by the low power state to which they belong));
execute the driver to:
transmit, via the interface, one request to the energy management device to read the block indicated by the block identifier, the block comprising the first data point and the second data point; and receive a value of the first data point and a value of the second data point via the interface responsive to the one request ([0033] the buffer may be written to a file. For example, the buffer, which as discussed above may be located in temporary storage in a cache of the processor, can be forwarded to a file system and may be stored, for example, in a system memory as a data file 220 for later access [0034] Referring now to FIG. 5, shown is a flow diagram of a method for processing collected data in accordance with an embodiment of the present invention. As shown in FIG. 5, method 250 may begin by processing data file 220 (block 260) (i.e., data file represents “block” of data identified and accessed in the temporary storage cache)).
Regarding claims 11, 13, 14, 17, and 20, they comprise limitations similar to claims 1, 13, 14, 17, and 20, and are therefore rejected for similar rationale.
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, 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 2, and 12 are rejected under 35 U.S.C. 103 as being unpatentable over KNIGHT, as applied to claims 1, and 11 above, and in further view of WASSERMAN et al. Pub. No.: US 2017/0344504 A1 (hereafter WASSERMAN).
Regarding claim 2, KNIGHT further teaches:
the instructions cause the one or more processors to: generate a namespace, the namespace comprising an indication of a predefined variable ([0011] Processor power state transition events track when a processor changes its current power state. Such power state transition events include active-to-sleep and sleep-to-active transitions. Note that as used herein, the terms “sleep state” and “low power state” may be used interchangeably to refer to a power state of a device that is less than a normal operating state. In such low power states, e.g., with reference to a processor, some components may remain powered on and functioning while other components are in a powered off state (i.e., sleep/low power states represent predefined logical groupings of states, or “namespaces”))…
read a value of the data point from the energy management device via the interface and provide the value to the instance of the predefined variable ([0031] For each possible sleep state available in the processor (as determined at diamond 130), a loop is traversed that includes reading the corresponding residency counter for that low power state (block 140), which may be realized via reading a MSR for the low power state, and writing the counter value to the entry in the buffer (block 150) (i.e., residency counters represent data points corresponding to power states, and are provided to a buffer as an instance of the predefined variable state)).
While KNIGHT discusses executing a driver to perform reading from, and writing data to memory, KNIGHT does not explicitly teach:
generate the driver to map a data point of the plurality of data points to an instance of the predefined variable;
execute a software application based on the namespace, the software application configured to operate based on the instance of the predefined variable; and
However, in analogous art that similarly teaches reading and writing data from a memory, WASSERMAN teaches:
generate the driver to map a data point of the plurality of data points to an instance of the predefined variable; execute a software application based on the namespace, the software application configured to operate based on the instance of the predefined variable ([0022] The master device comprises a software layer with variables and the description files (i.e., description files are used to classify data, and are therefore considered to be “namespaces”) are used to map the variables to the data read from and written to the generic driver (i.e., software application layer executes based on predefined variables mapped to data read from and written to a generated driver));
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined WASSERMAN’s teaching of a software application layer executes based on predefined variables mapped to data read from and written to a generated driver, with KNIGHT’s teaching of executing a driver to read or write energy management information, to realize, with a reasonable expectation of success, a system that executes a driver, as in KNIGHT, that allows a software application to execute based on predefined variables mapped to data read from and written to a generated driver, as in WASSERMAN. A person having ordinary skill would have been motivated to make this combination to reduce complexity for computing systems having large numbers of slave devices (WASSERMAN [0005]).
Regarding claim 12, it comprises limitations similar to claim 2, and are therefore rejected for similar rationale.
Claims 5-6, and 15-16 are rejected under 35 U.S.C. 103 as being unpatentable over KNIGHT, as applied to claims 1, and 11 above, and in further view of WILLIAMS et al. Pub. No.: US 2024/0063658 A1 (hereafter WILLIAMS).
Regarding claim 5, while KNIGHT discusses mapping values to data, KNIGHT does not explicitly teach:
generate the driver to map between the plurality of data points and a plurality of variables, wherein:
at least one variable of the plurality of variables is an object defined based on a class, the class defining a plurality of attributes for the object describing a data point of the plurality of data points; and
an attribute of the plurality of attributes comprising a rate to acquire a value of the data point at; and
execute the driver to read the value of the data point at the rate defined in the attribute of the object.
However, in analogous art that similarly discusses mapping values to data, WILLIAMS teaches:
generate the driver to map between the plurality of data points and a plurality of variables, wherein: at least one variable of the plurality of variables is an object defined based on a class, the class defining a plurality of attributes for the object describing a data point of the plurality of data points; and an attribute of the plurality of attributes comprising a rate to acquire a value of the data point at; and execute the driver to read the value of the data point at the rate defined in the attribute of the object ([0046] In some embodiments, the power monitor determines one or more or all of the above characteristics of the power drawn from the socket by the device, together with time-stamp information at intervals of between 3 Hz and 5 Hz, but preferably 3 Hz (i.e., interval frequency and time stamps represent two categories, or “classes” of “attributes” because they comprise a plurality of attributes related to collection of data points including an interval or “frequency” of data acquisition). [0045] The power monitor determines, one or more or all of the following characteristics of the power drawn from the socket outlet by the device, together with time-stamp information: an AC line frequency; an AC line voltage; a current drawn on outlet; an active power drawn on the outlet; a reactive power drawn on the outlet; an apparent power drawn on the outlet; and power factor. The time-stamp is a date-time stamp which is accurate to the nearest millisecond in some embodiments (i.e., characteristics represent “data points” collected at the intervals described by the frequency and timestamp ). [0198] Not shown in FIG. 1 for clarity are any supporting components such as, for example, passives, drivers and isolation circuitry which would be apparent to anyone of ordinary skill in the art to include (i.e., driver is used to implement data collection)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined WILLIAMS’s teaching of collecting data points of a power management system at a specified frequency, with KNIGHT’s teaching of collecting data points of a power management system, to realize, with a reasonable expectation of success, a system that collects data points of a power management system, as in KNIGHT, at a specified frequency, as in WILLIAM. A person having ordinary skill would have been motivated to make this combination to maintain accurate power management measurements through frequent collection.
Regarding claim 6, while KNIGHT discusses collection of data, KNIGHT does not explicitly teach:
generate the driver to map between the plurality of data points and a plurality of variables, wherein:
at least one variable of the plurality of variables is an object defined based on a class, the class defining a plurality of attributes for the object describing a data point; and
an attribute of the plurality of attributes comprising a rate to write a value of the data point to a software application;
execute the driver to write the value of the data point to the software application at the rate defined in the attribute of the object.
However, in analogous art that similarly discusses collection of data, WILLIAMS teaches:
generate the driver to map between the plurality of data points and a plurality of variables, wherein: at least one variable of the plurality of variables is an object defined based on a class, the class defining a plurality of attributes for the object describing a data point; and an attribute of the plurality of attributes comprising a rate to write a value of the data point to a software application; execute the driver to write the value of the data point to the software application at the rate defined in the attribute of the object ([0046] In some embodiments, the power monitor determines one or more or all of the above characteristics of the power drawn from the socket by the device, together with time-stamp information at intervals of between 3 Hz and 5 Hz, but preferably 3 Hz (i.e., interval frequency and time stamps represent two categories, or “classes” of “attributes” because they comprise a plurality of attributes related to collection of data points including an interval or “frequency” of data acquisition). [0045] The power monitor determines, one or more or all of the following characteristics of the power drawn from the socket outlet by the device, together with time-stamp information: an AC line frequency; an AC line voltage; a current drawn on outlet; an active power drawn on the outlet; a reactive power drawn on the outlet; an apparent power drawn on the outlet; and power factor. The time-stamp is a date-time stamp which is accurate to the nearest millisecond in some embodiments (i.e., characteristics represent “data points” collected at the intervals described by the frequency and timestamp ) [0359] FIG. 10A shows an example of an embodiment of a method for determining an energy usage classification for power drawn from a power outlet of a power socket by a device, the method comprising: receiving (step 1002), by an energy usage classification ML model 44 a trained as shown in FIG. 9 or disclosed elsewhere herein, an input vector comprising at least one or more power characteristics of power drawn by the device from the power outlet captured in a time segment and an identifier for a device type of the device; determining (step 1004) an energy usage classification using the trained energy usage classification ML model; and outputting (step 1006) an indication of the determined energy usage classification (i.e., determined energy usage classification is output, or “written” at the frequency, or “rate” that it is collected). [0198] Not shown in FIG. 1 for clarity are any supporting components such as, for example, passives, drivers and isolation circuitry which would be apparent to anyone of ordinary skill in the art to include (i.e., driver is used to implement data collection/output))).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined WILLIAMS’s teaching of collecting data points of a power management system and outputting information at a specified frequency, with KNIGHT’s teaching of collecting data points of a power management system, to realize, with a reasonable expectation of success, a system that collects data points of a power management system, as in KNIGHT, and outputs information at a specified frequency, as in WILLIAM. A person having ordinary skill would have been motivated to make this combination to maintain accurate power management measurements through frequent collection.
Regarding claims 15 and 16, they comprises limitations similar to claims 5 and 6, and are therefore rejected for similar rationale.
Claims 8, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over KNIGHT, as applied to claims 1, and 11 above, and in further view of HATTA et al. Pub. No.: US 2018/0203805 A1 (hereafter HATTA).
Regarding claim 8, while KNIGHT discusses identifying data, KNIGHT does not explicitly teach:
search the file to determine that a first data point and a second data point of the plurality of data points do not include a block identifier;
identify that the first data point and the second data point include consecutive addresses; generate, responsive to an identification that the first data point and the second data point include the consecutive addresses, a first variable for the first data point, the first variable comprising an attribute including an identifier of a block; and
generate, responsive to an identification that the first data point and the second data point include the consecutive addresses, a second variable for the second data point, the second variable comprising an attribute including the identifier of the block.
However, in analogous art that similarly discusses identifying data, HATTA teaches:
search the file to determine that a first data point and a second data point of the plurality of data points do not include a block identifier; identify that the first data point and the second data point include consecutive addresses; generate, responsive to an identification that the first data point and the second data point include the consecutive addresses, a first variable for the first data point, the first variable comprising an attribute including an identifier of a block; and generate, responsive to an identification that the first data point and the second data point include the consecutive addresses, a second variable for the second data point, the second variable comprising an attribute including the identifier of the block ([0057] The shared region management part 211 secures memory regions with consecutive addresses of the host physical address space as the shared region 221. The shared region management part 211 divides the secured memory region into respective blocks, and assigns an identification number to each of the blocks (i.e., blocks representing data points that have consecutive addresses and are not yet assigned identification numbers are searched for, and identified, and each block is assigned a block identifier attribute)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined HATTA’s teaching of identifying memory blocks having consecutive addresses, and assigning block identifier attributes to them, with KNIGHT’s teaching of reading data points from memory, to realize, with a reasonable expectation of success, a system that reads data points from memory, as in KNIGHT, which is organized by identifying memory blocks having consecutive addresses and having assigned block identifier attributes, as in HATTA. A person having ordinary skill would have been motivated to make this combination to reduce space and price of virtualized devices (HATTA [0005]).
Regarding claim 18, it comprises limitations similar to claim 8, and is therefore rejected for similar rationale.
Claims 9, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over KNIGHT, as applied to claims 1, and 11 above, and in further view of NEERJU et al. Pub. No.: US 2021/0294817 A1 (hereafter NEERJU).
Regarding claim 9, which KNIGHT discusses reading data points, KNIGHT does not explicitly teach:
compare a name of a data point indicated in the file to a plurality of names of a plurality of predefined variables;
determine, based on the comparison, that there is no match between the name of the data point and the plurality of names the plurality of predefined variables; and
instantiate a variable in a class for the data point responsive to a determination that there is no match between the name of the data point and the plurality of names of the plurality of predefined variables; and
populate a plurality of attributes of the variable based on data of the file for the data point.
However, in analogous art that similarly reads data points, NEERJU teaches:
compare a name of a data point indicated in the file to a plurality of names of a plurality of predefined variables; determine, based on the comparison, that there is no match between the name of the data point and the plurality of names the plurality of predefined variables ([0014] Data classification on structured data may be done by testing the values or the metadata or properties of each column against the classifiers associated to the searched data class. Each data class to be found is associated with a classifier which is a rule or heuristic defining how to decide if a tested value, or a column as a whole, matches the classification criteria of the data class or not…The result of the classification process is a list of data classes that are likely to match the data contained in each tested column and a confidence that the classification is a good representation of the column. However, there are many instances in which an automated system is not able to classify one or more columns in a data set (i.e., data that cannot be classified is data that does not match previously classified data)); and
instantiate a variable in a class for the data point responsive to a determination that there is no match between the name of the data point and the plurality of names of the plurality of predefined variables; and populate a plurality of attributes of the variable based on data of the file for the data point ([0049] Still referring to step 320, the module 150 creates a new data class for a particular unclassified column in the current data set based on determining that the particular unclassified column has a 1-to-1 relationship with a classified column in the current data set. In embodiments, the module 150 creates the new data class by creating a new class definition that is based on, for example, valid values of the new data class (e.g., all the values in the rows of the unclassified column) or a determined pattern (e.g., a regular expression, or regex) of values in the rows of the unclassified column. [0050] At step 325, the system applies the new data class (created at step 320) to at least one other unclassified column in the current data set. In embodiments, the module 150 pushes the new data class to applicable unclassified columns in the current data set. In embodiments, the module 150 compares the data in an unclassified column to the new class definition (e.g., valid values or regex) created at step 320, and classifies the unclassified column with the new data class when the data in an unclassified column matches the new class definition. In this manner, step 325 results in a previously unclassified column being classified with the new data class).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined NEERJU’s teaching of creating a new classification for data that does not match previously classified data, with KNIGHT’s teaching of reading data points, as in KNIGHT, to realize, with a reasonable expectation of success, a system that reads data points, as in KNIGHT, and classifies data that does not match previously classified data, as in NEERJU. A person having ordinary skill would have been motivated to make this combination to improve classification of previously unclassifiable data.
Regarding claim 19, it comprises limitations similar to claim 9, and is therefore rejected for similar rationale.
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over KNIGHT, as applied to claim 1 above, and in further view of CHIRCOP et al. Pub. No.: US 2018/0136880 A1 (hereafter CHIRCOP).
Regarding claim 10, which KNIGHT discusses reading data points, KNIGHT does not explicitly teach:
identify an encoding of a value of a data point of a plurality of data points based on the file;
generate an instance of a variable in a class, the class comprising a plurality of attributes;
store an indication of the encoding in an attribute of the plurality of attributes; and
execute the driver to: read the encoding from the attribute; and decode the value of the data point based on the encoding.
However in analogous art, that similarly reads data points, CHIRCOP teaches:
identify an encoding of a value of a data point of a plurality of data points based on the file; generate an instance of a variable in a class, the class comprising a plurality of attributes ([0057] If, at decision point 201, it has been determined that encoding is required, at block 202, the storage system will apply one or more encoding methods to the data block and then determine if the encoding is appropriate (i.e., applying an encoding method “identifies” an encoding of a data block having at least attributes of size, and encoding type));
store an indication of the encoding in an attribute of the plurality of attributes ([0063] The storage system will generate an identifying sequence for the encoded data block at block 205 (e.g., using at least a portion of the encoded data as described, for example, with reference to FIG. 5) and at block 206 will prepend a frame header 103 (FIG. 2B) containing the size of the newly encoded data block as well as the type of encoding that was utilized to encode the data. At block 207, the storage system will also prepend the identifying sequence 102 (FIG. 2B) for the encoded data block and at block 208 will persist the data block 160 in the format as shown in FIG. 2B); and
execute the driver to: read the encoding from the attribute; and decode the value of the data point based on the encoding ([0074] If the encoding type or types 103 has been derived from the prepended frame header (e.g., it has been determined at decision point 306 from the frame header that the data has been encoded), then the storage system can apply the appropriate decoding method or methods at block 308 to the data block. Once the decoding has been applied, the storage system will be able to use the decoded data at block 309 in the previous unencoded format as shown in FIG. 2A).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined CHIRCOP’s teaching of encoding and decoding data points, with KNIGHT’s teaching of reading data points, to realize, with a reasonable expectation of success, a system that encodes and decodes data points, as in CHIRCOP, in order to read the data points, as in KNIGHT. A person having ordinary skill would have been motivated to make this combination to improve security of data within the system through use of encoding.
Conclusion
HSE Pub. No.: US 2014/0181324 A1 discusses executing driver codes to load control commands to execute operations such as data writing, reading, and erasing.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL W AYERS whose telephone number is (571)272-6420. The examiner can normally be reached M-F 8:30-5 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, Aimee Li can be reached at (571) 272-4169. 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.
/MICHAEL W AYERS/ Primary Examiner, Art Unit 2195
Prosecution Insights