DETAILED ACTION
This Office Action is in response to claims filed 12/01/2025.
Claims 1-6 and 8-21 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 .
Response to Arguments
Applicant’s arguments, see page 8 of remarks, filed 12/01/2025, with respect to drawing objection of Fig. 1 have been fully considered and are persuasive. The drawing objection of 07/29/2025 has been withdrawn.
Applicant’s arguments, see page 8 of remarks, filed 12/01/2025, with respect to specification objections have been fully considered and are persuasive. The specification objection of 07/29/2025 has been withdrawn.
Applicant’s arguments, see page 8 of remarks, filed 12/01/2025, with respect to claim objections of 7, 10, 13, 17 and 22 have been fully considered and are persuasive. The claim objections of 07/29/2025 has been withdrawn.
Applicant’s arguments, see page , filed 12/01/2025, with respect to the 35 U.S.C. 101 rejection of have been fully considered and are persuasive. The 35 U.S.C. 101 rejection of 07/29/2025 has been withdrawn.
Applicant’s arguments, see page , filed 12/01/2025, with respect to the 35 U.S.C. 112(f) interpretation and subsequent 35 U.S.C. 112(a) and 112(b) rejections of claims 20-21 have been fully considered and are persuasive. Upon reconsideration in view of Applicant’s remarks, the term “a sensor element” conveys sufficient structure, as the term “sensor” is understood by a person of ordinary skill in the art to denote a physical component configured to detect physical stimulus capable of performing the recited function. The 35 U.S.C. s of 07/29/2025 has been withdrawn.
Applicant's arguments filed 12/01/2025 have been fully considered but they are not persuasive. The Applicant argues in substance:
Claims 7-8 and 20-21 were provisionally rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claims 8-11 of copending U.S. Application No. 18/067,046, filed December 16, 2022, U.S. 20230195549 A2, published June 22, 2023, issued as Patent No. 12,423,168 on September 23, 2025 (the “168 Patent”). Applicant respectfully submits that the provisional double patenting rejection of claims 7-8 and 20-21 does not require a response at this time. Applicant will address the rejection in due course should the double-patenting rejection apply to a patent resulting from the co-pending application and should a terminal disclaimer ultimately be appropriate, neither of which currently is applicable in the present application.
With regard to point (a), Examiner has considered Applicant’s remark. However, because the basis for the rejection remains unchanged and no terminal disclaimer has been filed, the non-statutory double patenting rejection raised in the previous Office Action, filed 07/29/2025, continues to stand and will be reiterated below.
Applicant’s arguments with respect to claim 1 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Objections
Claim 12 is objected to because of the following informalities: Claim 12 remains improperly dependent on newly canceled claim 7. For purpose of examination, claim 12 will be read as dependent from claim 1. Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-6, and 8-21 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
The following claim language is unclear
With regard to claim 1, line 7, recites “selecting the app via a communication interface of the sensor using a higher level unit.” It is unclear from the context of the claim to ascertain the structure or specific implementation of the higher level unit. A review of the specification reveals no clear structural component or illustrative embodiment that allows for one of ordinary skill in the art to ascertain the scope of the invention. More specifically, it is unclear what particular device or entity is performing the selecting. For purpose of examination, the Examiner will reasonably interpret the limitation as any system component, device, hardware, firmware, software method, or user entity capable of performing supervisory or administrative functions over sensor functionality.
Claim 1 recites the limitation "the firmware" in line 4. There is insufficient antecedent basis for this limitation in the claim. For examination purposes, the limitation of claim 1, line 4 will be read as “a firmware.”
Claim 1 recites the limitation "the name and version" in lines 5-6. There is insufficient antecedent basis for this limitation in the claim. For examination purposes, the limitation of claim 1, lines 5-6 will be read as “a name and a version.”
Claim 17 recites the limitation “interpreters/compilers” in line 2, which is overly broad and lacks sufficient clarity. It is unclear whether the “/” in the limitation is to represent “and”, “or”, or both. For the purpose of compact prosecution and applying art, Examiner will interpret the limitation as “at least one of interpreters or compilers.”
Claims 2-6, and 8-21 depend upon claim 1 and are therefore additionally rejected under 35 U.S.C. 112(b) or 35 U.S.C. (pre-AIA ), second paragraph, as being indefinite.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 8, 20, and 21 are provisionally rejected on the ground of non-statutory double patenting as being unpatentable over claims 8-11 of co-pending Application No. 18/067,046 (hereinafter ‘046). Although the claims at issue are not identical, they are not patentably distinct from each other because the claims of 18/067,046 are narrower in scope and anticipate the instant claims. Further, the instant claims recite “a sensor” whereas ‘046 recites the same limitations performed by “a basic system,” however, ‘046 discloses that “the basic system is a sensor” and thus the scope is commensurate. Additionally, the instant application recites a limitation of detecting “a measured variable” whereas ‘046 recites the same limitation of detecting “a measurand.” A measurand is a state, quantity, or property variable intended to be measured and thus the scope is commensurate.
This is a provisional non-statutory double patenting rejection.
Instant Application
Co-pending Application: 18/067,046
8. The method according to claim 1,
wherein the sensor comprises a plurality of apps.
8. The method according to claim 1,
wherein the basic system comprises a plurality of apps.
20. A sensor for executing the method according to claim 1, comprising:
a sensor element for detecting a measured variable of a measurement medium;
a data processing unit with a memory.
10. A sensor for executing the method of claim 1, comprising
a sensor element for detecting a measurand of a measurement medium,
a data processing unit with a memory.
21. The sensor according to claim 20, wherein the sensor is designed as an optical sensor with a light source and a light receiver.
11. The sensor according to claim 10, wherein the sensor is designed as an optical sensor with a light source and a light receiver; the sensor is a spectrometer.
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 1, 3, 4, 6, 14-17, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Rohrl et al. Pub. No. US 2014/0147030 A1 (hereinafter Rohrl) in view of Adams et al. Pub. No. US 2014/0189679 A1 (hereinafter Adams) in view of Guenschel DE 10 2014 211 074 A1 (hereinafter Guenschel).
With regard to claim 1, Röhrl teaches a method for expanding application possibilities of a sensor, comprising the steps of ([0001], This invention relates to a sensor for checking value documents, to an apparatus for checking value documents which has the sensor, and to a method for operating the sensor):
transmitting an app to the sensor via a communication interface of the sensor ([0015], Preferably, the sensor is equipped with a communication interface via which data can be loaded into the sensor. Via the communication interface the sensor can e.g. receive data and/or control commands from an apparatus for accepting and/or dispensing value documents or send them thereto; [0017], In a second embodiment example, The sensor, in particular the sensor firmware contained in the non-volatile memory, is set up to load the adaptation data and/or the software via the communication interface of the sensor directly to the sensor, and to store it in the volatile memory of the sensor) when the app is not yet located on the sensor ([0009], The sensor does have a non-volatile memory containing firmware of the sensor, but this non-volatile memory does not store any software or any adaptation data),
wherein the firmware of the sensor is configured to receive and store apps ([0010], In particular, it is specified in the firmware of the sensor, in particular through a basic operating system of the sensor contained in the firmware, that the software as well as the adaptation data are loaded into the sensor from outside the sensor, and stored in a volatile memory of the sensor);
wherein the app comprises at least identification features, including the name and version (Fig. 2a, Software, Version; [0049], In FIG. 2a there are represented by way of example the constituents of software SW which the sensor 1 can employ for checking the value documents W. This example involves the version 1.7 of the software employable for the sensor 1), …, and a main logic ([0049], Besides basic software which the sensor necessarily requires for checking the value documents, the software includes three software options 20 with the designations “XY”, “FT” and “QR” … through these software options 20 the sensor 1 can be given extended functions);
selecting the app via a communication interface of the sensor using a higher level unit via the identification features of the app ([0049], the software includes three software options 20 with the designations “XY”, “FT” and “QR” which the sensor operator can optionally acquire for the sensor 1 and can enable for his sensor 1; [0052], The license data L contains several single licenses and are compiled individually for the respective senor 1, in dependence on which constituents of the software SW and of the adaptation data A the sensor operator wishes to utilize. The sensor operator receives the flash card 10 with the selection of single licenses desired by him);
executing the selected app, wherein the sensor calls the entry point ([0010], It is provided here that the software and the adaptation data are only loaded into the sensor when the sensor is to be operated for checking the value documents. The sensor is configured to subsequently execute the software stored in volatile memory; [0044], As soon as software SW and adaptation data A have been loaded from the flash card into the volatile memory 9, the processor can execute the software)
However, Röhrl does not explicitly teach that identifications features including entry points. Additionally, Röhrl does not explicitly teach that execution of the app occurs through an entry point and that an application returns a value.
Adams teaches one or more entry points ([0174], Embodiments of the present invention use the concept of binary code library linkage, whereby separate areas of application functionality can be compiled separately into multiple code libraries, and later linked together to form a single executable application. Each library advertises a linkage points through a table of “function entry points” (points that other libraries can link to);
executing the selected app, … call[ing] the entry point ([0304], The flow of execution of the App Binary can be examined by considering each line of the source in turn; [0305], “main()” – this entry point function is first called when the App Binary (H2) is first executed within the host environment); and
returning at least one return value from the app to the sensor ([0308], The flow of communication and execution is the same as for “s3eAccelerometerStart()”, noting that in these cases the function calls do return a value, which is ultimately returned to the host environment loader)
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Adams with the teachings of Röhrl in order to provide a method that teaches the features and flow of application execution. The motivation for applying Adams teaching with Röhrl teaching is to provide a method that allows for distinct stages of an applications execution flow to be optimized, thereby allowing the use of optimized code modules and libraries to improve application performance (Adams, [0174]-[0175]). Röhrl and Adams are analogous art directed towards program initialization. Therefore, it would have been obvious for one of ordinary skill in the art to combine Adams with Röhrl to teach the claimed invention in order to provide segments of application stages such that allows for the integration of optimized code modules and libraries such that improves application performance and enables modular development.
However, the combination does not explicitly teach the operation of the sensor using an application configured to calculate measured values.
Guenschel teaches wherein the app is an app for calculating a measured value via a model ([0014], Another aspect is that a computer program is provided which includes program code for carrying out the method for operating a sensor device, when the computer program is executed on a computer, in particular a sensor device; [0010], a procedure for operating the sensor device is provided, comprising the following steps: Measuring a physical quality using the sensor)
wherein the sensor of the app transfers the raw value as a parameter, or the app calls the raw value via the application programming interface ([0010], Sending the recorded position and a measurement-based value to a server via a communication network using the communication interface),
wherein the main logic comprises algorithms for signal processing and routines for calculating the measured value from the raw value via the model ([0010], Receiving, via the communication interface from the server via the communication network, a reference measurement value assigned to the detected position and/or a correction value assigned to the detected position, Determining a correction value based on the reference measurement and the measure value using the processing unit), and
wherein the measured value is the return value ([0020], The value output by the sensor is mathematically corrected based on the correction value(s) so that the correction value corresponds to the correct measured value (Examiner notes: such that raw values measured by a sensor are transformed by an application to return the appropriate measured value).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Guenschel with the teachings of Röhrl and Adams in order to provide a method that teaches operation of a sensor with an application. The motivation for applying Guenschel teaching with Röhrl and Adams teaching is to apply the well-known method of transmitting sensor-captured data to a software application for processing in order to enable derived values through computation using such flexible program logic, which would have yielded predictable results. Röhrl and Adams and Guenschel are analogous art directed towards arrangement of measuring variables and measuring instruments. Therefore, it would have been obvious for one of ordinary skill in the art to combine Guenschel with Röhrl and Adams to teach the claimed invention in order to provide flexible application processing of sensor-captured data to produce measured values from raw data.
With regard to claim 3, Adams teaches the method according to claim 1, wherein the sensor comprises an application programming interface (API) ([0285], The most common application development scenario is that the App Binary is compiled for the host CPU architecture (typically x86), and the host loader (typically compiled for x86, and running on Windows, OSX, or Linux) dynamically links to and executes the App Binary. The App Binary makes the function calls to the Loader through its external dependencies, namely the OS abstraction APIs), and the app queries one or more parameters of the sensor ([0302], //Get the accelerometer X, Y, Z values (Examiner notes: application queries sensors for parameters); [0308], “s3eAccelerometerGetX(), GetY(), GetZ()” – the App Binary makes these calls to the OS abstraction API. The host environment Loader receives these calls, but the host environment has been configured so as to re-route these calls to the target device)
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Adams with the teachings of Röhrl and Guenschel in order to provide a method that teaches an application programming interface and an application querying parameters of the device. The motivation for applying Adams teaching with Röhrl and Guenschel teaching is to provide a method that introduces an abstraction for interfacing with the operating system and peripheral components, thereby enabling the application to be OS-agnostic and portable across operating system platforms (Adams, [0175]-[0179]). Röhrl, Guenschel, and Adams are analogous art directed towards program initialization. Therefore, it would have been obvious for one of ordinary skill in the art to combine Adams with Röhrl and Guenschel to teach the claimed invention in order to provide a general communication interface to increase portability across a range of operating system platforms.
With regard to claim 4, Adams teaches the method according to claim 1, wherein the sensor cyclically calls the entry point (Fig. 5b, 0x4a000354 <main+84>: bne 0x4a000308 <main+8> (Examiner notes: Depicted is the disassembled implementation of the s3eDeviceCheckQuitRequest() where an instruction BNE (Branch if Not Equal) determines if the application has exited through comparison of the exit flag. If instruction resolves true, the exit flag had not been set and execution of program will jump to the inner loop instruction specified, <main+8>, which loops back to the main entry point, cyclically. However, if instruction resolves false, the exit flag had been set and execution of program will continue to the next immediate instruction <main+88>, which performs the return and exit of application); [0278], Referring now to FIGS. 5A and 5B of the accompanying drawings: [0280], 2. The disassembly of the APP binary compiled for ARM shows how the lines of source code become ARM CPU instructions … the Loader invokes the QEMU environment to continue emulated execution from the next ARM instruction (in this case, instruction “mov r3, r0”); emulated execution then continues until the next disassembled “s3e” function (i.e., the next “b1 …” instruction), at which point a similar pattern is repeated).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Adams with the teachings of Röhrl and Guenschel in order to provide a method that teaches a device cyclically calling the entry point of an application. The motivation for applying Adams teaching with Röhrl and Guenschel teaching is to provide a method that combines a reconfigurable sensor system, as disclosed by Röhrl, Guenschel, and Adam, with an application that can continuously perform processes, as disclosed by Adam, to achieve the predictable result of robust, persistent sensor functionalities. Röhrl, Guenschel, and Adams are analogous art directed towards program initialization. Therefore, it would have been obvious for one of ordinary skill in the art to combine Adams with Röhrl and Guenschel to teach the claimed invention in order to provide application execution persistence.
With regard to claim 6, Adams teaches the method according to claim 1, wherein the step “returning at least one return value from the app to the sensor” is carried out by the sensor comprising an application programming interface via which the app communicates the return value to the sensor ([0286], Embodiments of the present invention seek to extend this scenario, whereby a target device (Examiner notes: a sensor component) running a target loader module appropriate for the device is connected to the host loader module of the host environment (Examiner notes: a sensor device) through a target interface module in the form of an application running on the target device … The host Loader remains the same (typically compiled for x86, and running on Windows, OSX, or Linux). Whenever the App Binary (running within the host environment) makes a function call (functional command) to the OS abstraction API (Examiner notes: application communicates through API), the host environment Loader checks to see if a target device is connected to the host environment in such a way that this particular function call should be re-routed to the target device … If such a communication link exists, and the host environment has been configured to re-route this function call remotely, then the host environment Loader issues a command to the Remote Client application to execute the function call using the target device Loader, and return the result value to the environment Loader)
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Adams with the teachings of Röhrl and Guenschel in order to provide a method that teaches returning a value is performed by an application programming interface between the application and the sensor device. The motivation for applying Adams teaching with Röhrl and Guenschel teaching is to provide a method that provides an efficient communication arrangement such that allows for host devices to issue functional commands to components and receive result values in return (Adams, [0136]-[0137]) . Röhrl, Guenschel, and Adams are analogous art directed towards program initialization. Therefore, it would have been obvious for one of ordinary skill in the art to combine Adams with Röhrl and Guenschel to teach the claimed invention in order to provide a standardized communication interface that enables predictable interactions between an application and its system.
With regard to claim 14, Adams teaches the method according to claim 1, wherein the sensor comprises an interpreter, the app is present on the sensor in an interpretable format, and the app is executed via the interpreter ([0012], When the application is executed, the bytecode is interpreted by the VM and converted into machine code native to the CPU of the device. This conversion process can happen on-the-fly every time each bytecode instruction is interpreted).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Adams with the teachings of Röhrl and Guenschel in order to provide a method that teaches application execution performed by an interpreter. The motivation for applying Adams teaching with Röhrl and Guenschel teaching is to provide a method that allows for applications to be in the purest form of binary portability (Adams, [0014]), such that enables a wide variety of device types to execute the application. Röhrl, Guenschel, and Adams are analogous art directed towards program initialization. Therefore, it would have been obvious for one of ordinary skill in the art to combine Adams with Röhrl and Guenschel to teach the claimed invention in order to provide instruction translation system that achieves platform-independent execution of code.
With regard to claim 15, Adams teaches the method according to claim 1, wherein the sensor comprises a just-in-time compiler, and the app is present in a corresponding format on the sensor ([0012], When the application is executed, the bytecode is interpreted by the VM and converted into machine code native to the CPU of the device. This conversion process can happen … “Just In Time” (JIT) by interpreting a block of instructions, converting to machine code, and caching the resulting code in memory so that it does not need to be converted again within the same execution of the application).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Adams with the teachings of Röhrl and Guenschel in order to provide a method that teaches application execution performed by a Just-In-Time compiler. The motivation for applying Adams teaching with Röhrl and Guenschel teaching is to provide a method that allows for two stage compilation involving compilation into an intermediary binary code, such that enables portability between multiple device platforms, and compilation of the bytecode to a CPU native machine code, improving performance, or interpretation (Adams, [0015]). Röhrl, Guenschel, and Adams are analogous art directed towards program initialization. Therefore, it would have been obvious for one of ordinary skill in the art to combine Adams with Röhrl and Guenschel to teach the claimed invention in order to provide instruction translation system that achieves flexibility of code portability and runtime efficiency.
With regard to claim 16, Adams teaches the method according to claim 1, wherein the sensor comprises an ahead-of-time compiler, and the app is in a corresponding format on the sensor ([0012], When the application is executed, the bytecode is interpreted by the VM and converted into machine code native to the CPU of the device. This conversion process can happen … “Ahead Of Time” (AOT) by applying the JIT process to the entire bytecode as soon as the application is launched).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Adams with the teachings of Röhrl and Guenschel in order to provide a method that teaches application execution performed by an Ahead-Of-Time compiler. The motivation for applying Adams teaching with Röhrl and Guenschel teaching is to provide a method that allows for a single compilation involving compilation of source code targeted towards the particular device, providing the best compiled performance (Adams, [0019]-[0020]). Röhrl, Guenschel, and Adams are analogous art directed towards program initialization. Therefore, it would have been obvious for one of ordinary skill in the art to combine Adams with Röhrl and Guenschel to teach the claimed invention in order to provide instruction translation system that achieves optimal runtime efficiency of code.
With regard to claim 17, Adams teaches the method according to claim 1, wherein a plurality of at least one of interpreters or compilers can be executed per the sensor ([0106], Preferably, the system further comprises a system for producing an executable application which incorporates: an interface for selecting a processor type and operating system, a compiler to generate a code module comprising instructions which are executable by a processor type selected using the interface; [0175], Embodiments of the invention allow an application to be compiled as a code module which is preferably a CPU-dependent, but OS-agnostic, binary code library (an “App Binary”), allowing the developer to leverage all optimizations available from supporting compilers).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Adams with the teachings of Röhrl and Guenschel in order to provide a method that teaches a device executing a compiler to generate machine-readable instructions. The motivation for applying Adams teaching with Röhrl and Guenschel teaching is to provide a method that allows for translation of high-level, human-readable application code to machine-executable instructions. Employing a compiler and interpreter with a sensor device applies a known technique of compilation and interpretation to a known class of device, embedded systems, to achieve predictable results. Such predictable results include improved portability of an application across different hardware platforms and optimized machine-executable instructions generated for the particular hardware platform. Röhrl, Guenschel, and Adams are analogous art directed towards program initialization. Therefore, it would have been obvious for one of ordinary skill in the art to combine Adams with Röhrl and Guenschel to teach the claimed invention in order to provide compilers and interpreters to a sensor system in order to facilitate flexible application deployment and improve system efficiency in a predictable manner.
With regard to claim 20, Röhrl teaches a sensor for executing the method according to claim 1, comprising (Abstract, A sensor for checking value documents, an apparatus with the sensor, and a method for operating the sensor):
a sensor element for detecting a measured variable of a measurement medium ([0007], The sensor configured for checking the value documents has … a measuring device for collecting measuring data of the value documents to be checked … The sensor is set up to execute the software stored temporarily in the volatile memory in order to collect measuring data of the value documents through the measuring device);
a data processing unit ([0007], The sensor configured for checking the value documents has … a processor for controlling the sensor and for evaluating the measuring data) with a memory ([0007], The sensor configured for checking the value documents has a non-volatile memory which is permanently installed in the sensor).
Claims 2 and 5 are rejected under 35 U.S.C. 103 as being unpatentable over Röhrl in view of Adams in view of Guenschel, as applied to claim 1 above, and further in view of Vahid et al. “Embedded System Design: A Unified Hardware/Software Approach” (hereinafter Vahid).
With regard to claim 2, the combination does not explicitly teach that during execution of the app, the sensor provides one or more parameters to the entry point.
Vahid teaches the method according to claim 1, wherein during the execution of the app, the sensor provides one or more parameters to the entry point (Pg. 30, When a program requires some service from the operating system, it generates a predefined software interrupt that is serviced by the operating system. Parameters specific to the requested services are typically passed from (to) the application program to (from) the operating system through CPU registers; Pg. 74, Figure 6.5: Interrupt-driven I/O using fixed ISR location, 1. Microprocessor is executing its program, say current program counter (PC) = 100, 2. Peripheral1’s input device stores new data in register 0x8000 (Examiner notes: parameters), Peripheral1 asserts Int to request servicing by microprocessor of the new data, 4. Microprocessor stops executing its program and stores state, including PC, 5. Microprocessor jumps to fixed location of ISR at program memory location 16 (set PC=16) (Examiner notes: entry point of the requested routine), 6. ISR reads data from 0x8000 (Examiner notes: routine reads parameter(s) provided by system from entry point), modifies the data, and writes to 0x8001, 7. ISR returns, causing restoration of the microprocessor state, thus setting PC = 100+1 = 101, 8. Microprocessor resumes executing its program)
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Vahid with the teachings of Röhrl, Adams, and Guenschel in order to provide a method that teaches a system capable of supplying parameters to the entry point of an application. The motivation for applying Vahid teaching with Röhrl, Adams, and Guenschel teaching is to provide a method that allows for processing of data from peripheral components at unpredictable intervals concurrent to program execution such thereby enabling improvements to system resource efficiency and responsiveness (Vahid, Pg. 72-74). Röhrl, Adams, Guenschel, and Vahid are analogous art directed towards program execution arrangements and embedded systems. Therefore, it would have been obvious for one of ordinary skill in the art to combine Vahid with Röhrl, Adams, and Guenschel to teach the claimed invention in order to provide a method of handling a plurality of peripheral data using interrupt-driven I/O, thereby improving resource efficiency and responsive of embedded data communication.
With regard to claim 5, the combination does not explicitly teach a direct return.
Vahid teaches the method according to claim 1, wherein the step “returning at least one value from the app to the sensor” is carried out as a direct return of the app to the sensor (Pg. 24, Branches can be further categorized as being unconditional jumps, conditional jumps or procedure call and return instructions … A call instruction, in addition to indicating the address of the next instruction, saves the address of the current instruction so that a subsequent return can jump back to the instruction immediately following the most recent invoked call instruction. This pair of instructions facilitates the implementation of procedure/function call semantics of high-level programming languages … An operand field specifies the location of the actual data that takes part in an operation … The operand field may indicate the data’s location through one of several addressing modes, illustrated in Figure 2.5; Pg. 25, In direct addressing, the operand field contains the address of a memory location in which the data resides (Examiner notes: When executed, a return instruction performs a branch to the previously saved address. With direct addressing, the return operand is the address pointing to the next instruction in memory ready for execution, thereby performing a direct return of a routine to a device).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Vahid with the teachings of Röhrl, Adams, and Guenschel in order to provide a method that teaches returning a value from application to device is performed as a direct return. The motivation for applying Vahid teaching with Röhrl, Adams, and Guenschel teaching is to provide a method that allows for efficient and immediate resumption of execution after completion of a subroutine at a separate memory address. A direct return best minimizes instruction latency and preserves the program’s control flow integrity by directly accessing the instruction in memory to immediately resume program execution over other addressing modes (Vahid, Pg. 24). Röhrl, Adams, Guenschel, and Vahid are analogous art directed towards program execution arrangements and embedded systems. Therefore, it would have been obvious for one of ordinary skill in the art to combine Vahid with Röhrl, Adams, and Guenschel to teach the claimed invention in order to provide optimal program control flow and minimal instruction latency through the use of direct addressing return.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Röhrl in view of Adams, as applied to claim 1 above, and further in view of Kempf et al. Pub. No. US 2020/0104108 A1 (hereinafter Kempf).
With regard to claim 8, the combination does not explicitly teach a plurality of applications.
Kempf teaches the method according to claim 1, wherein the sensor comprises a plurality of apps ([0010], A plurality of further application programs, each of which contain at least one additional functionality for the field device).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Kempf with the teachings of Röhrl and Adams in order to provide a method that teaches a device comprising a plurality of apps. The motivation for applying Kempf teaching with Röhrl and Adams teaching is to provide a method that allows for a variety of different applications to be readily available for selection, thereby enabling flexible deployment and execution of relocatable object code relevant to a customer (Kempf, [0005]) while maintaining the efficiency benefits of natively executing an application (Kempf, [0007]). Röhrl, Adams, and Kempf are analogous art directed towards software design arrangements. Therefore, it would have been obvious for one of ordinary skill in the art to combine Kempf with Röhrl and Adams to teach the claimed invention in order to provide a method of deploying modular functionality to resource-constrained embedded devices.
Claims 9-11 are rejected under 35 U.S.C. 103 as being unpatentable over Röhrl in view of Adams in view of Guenschel, as applied to claim 1 above, and further in view of Kempf in view of Tampke Patent No. US 7,859,403 B2 (hereinafter Tampke).
With regard to claim 9, Kempf teaches the method according to claim 1, wherein the sensor comprises a plurality of apps ([0010], A plurality of further application programs, each of which contain at least one additional functionality for the field device)
Rationale to claim 8 is applied here.
However, Kempf does not explicitly teach the remaining limitations.
Tampke teaches each app comprises a different model (Col. 3, lines 37-43, According to one aspect, the facility 104 is, for example, a natural gas transmission or distribution facility such as a natural gas pipeline. In this example, the measurement data may comprise natural gas transmission or distribution pressures, natural gas odorant levels, natural gas flow rates, or any other natural gas parameter (sensor models) that can be measured at the natural gas pipeline; Col. 3-Col.4, lines 65-67 and lines 1-3, The example facilities describe above are not exhaustive, but rather are illustrative of some of the facilities where MAS 100 can be implemented. It is contemplated that the MAS 100 can be used with any facility for which measurement data for a particular operation or process can be collected and communicated) for calculating a measured value (FIG. 4, Measure a particular operating parameter and generate measurement signal 402; Col. 10, lines 49-56, FIG. 4 illustrates a method for selectively communicating measurement data from a field device (e.g., RTU 106) according aspects of the monitoring and alarming system illustrated in FIGS. 1 and 2. At 402, the sensor measures a particular operating parameter at the facility 104 and generates the measurement signal 204. The measurement signal 204 is converted to a value at 404. At 406, the measurement value is stored in the memory 210).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Tampke with the teachings of Röhrl, Adams, Guenschel, and Kempf in order to provide a method that teaches a sensor performing different models of measurements. The motivation for applying Tampke teaching with Röhrl, Adams, Guenschel, and Kempf teaching is to provide a method that allows for a plurality of different measurements to be gathered through different applications, thereby maximizing the functionality of a sensor and enabling flexibility such that certain functionalities are transferable across multiple fields of use (Tampke, Col. 3). Röhrl, Adams, Guenschel, Kempf, and Tampke are analogous art directed towards embedded systems. Therefore, it would have been obvious for one of ordinary skill in the art to combine Tampke with Röhrl, Adams, Guenschel, and Kempf to teach the claimed invention in order to provide specialized applications capable of supporting multiple measurements types, thereby enhancing sensor functionality and enabling reuse across transferable operations.
With regard to claim 10, Tampke teaches the method according to claim 9, wherein the measured values from the different apps are compared, and a measured value is selected in the event of a deviation (Fig. 4, 408, Compare measurement value to threshold data to determine if event has occurred and event type; Col. 10, lines 56-63, Threshold data 218 is retrieved from the memory 210 and compared to the measurement value to determine if a transfer event, an alarm event, or a non-event has occurred at 408. For example, the measurement value is compared to an ideal operating range of values and maximum and minimum values for the particular operating parameter to determine if a transfer event or alarm event has occurred).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Tampke with the teachings of Röhrl, Adams, Guenschel, and Kempf in order to provide a method that teaches comparison of measurements and selection of deviations. The motivation for applying Tampke teaching with Röhrl, Adams, Guenschel, and Kempf teaching is to provide a method that allows for anomaly and fault detection and isolation thus enhancing data reliability and reconfigurability (Tampke, Col. 8). Röhrl, Adams, Guenschel, Kempf, and Tampke are analogous art directed towards embedded systems. Therefore, it would have been obvious for one of ordinary skill in the art to combine Tampke with Röhrl, Adams, Guenschel, and Kempf to teach the claimed invention in order to provide anomaly detection through comparison of measured data and isolation of deviated measurements for further consideration and review.
With regard to claim 11, Tampke teaches the method according to claim 9, wherein the measured values from the different apps are compared, and an alarm is triggered in the event of a deviation above a threshold value (FIG. 4, 418-420, Alarm Event Detected; Col. 11, lines 22-29, If the comparison at 408 determines the measurement value has breached (i.e., less than or greater than) the maximum and minimum values, and alarm event is detected at 418. After detecting the alarm event, the RTU 106 generates the notification signal 108 comprising an alarm message and measurement data 212 that is communicated to the telecommunication device 110 via the telecommunication network 112 using a telecommunication protocol 420).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Tampke with the teachings of Röhrl, Adams, Guenschel, and Kempf in order to provide a method that teaches a deviation event of measured values triggering an alarm signal. The motivation for applying Tampke teaching with Röhrl, Adams, Guenschel, and Kempf teaching is to provide a method that allows for desired destination devices to receive measurement and alarm data collected (Tampke, Col. 3). Röhrl, Adams, Guenschel, Kempf, and Tampke are analogous art directed towards embedded systems. Therefore, it would have been obvious for one of ordinary skill in the art to combine Tampke with Röhrl, Adams, Guenschel, and Kempf to teach the claimed invention in order to provide transmission of alarm signals upon detection of a deviation, thereby increasing system visibility and awareness, and enables control mechanisms to initiate responsive actions.
Claim 12 are rejected under 35 U.S.C. 103 as being unpatentable over Röhrl in view of Adams in view of Guenschel, as applied to claim 1 above, and further in view of Berg et al. Patent No. US 8,935,133 B1 (hereinafter Berg).
With regard to claim 12, Berg teaches the method according to claim 1, wherein the model is configured for a single measurement point (Col. 2, lines 37-48, Additionally, or alternatively, model 110 may include measurement points 160. Measurement points 160 may enable measurements to be taken with respect to a function, a process, an operation, a behavior, or another type of characteristic (e.g., an operational characteristic) corresponding to a given block 130 or group of blocks 130. Continuing with the example described above, where blocks 130 correspond to electrical circuit components, measurement points 160 may enable a user to take a measurement corresponding to an electrical current, an electrical potential, an electrical resistance, an electrical continuity, a component integrity, or another type of characteristic corresponding to blocks 130; Col. 10, lines 1-7, In addition, the description provided below with reference to FIGS. 8-12 demonstrate that switches 780 may be used to transition from one measurement mode to another mode in order to measure different characteristics of inside circuit component 720 and/or outside circuit component 730. Thus, a single measurement point 560 may be used to perform various different types of measurements).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Berg with the teachings of Röhrl, Adams, and Guenschel in order to provide a method that teaches a model configured for a single measurement point. The motivation for applying Berg teaching with Röhrl, Adams, and Guenschel teaching is to provide a method that designates an interface for measurement, such that enables a user and other systems to engage with the model in determining a condition, a behavior, or a characteristic (Berg, Col. 1). Röhrl, Adams, Guenschel, and Berg are analogous art directed towards design optimization. Therefore, it would have been obvious for one of ordinary skill in the art to combine Berg with Röhrl, Adams, and Guenschel to teach the claimed invention in order to provide a single measurement point to a sensor system, exposing an interface for a plurality of measurements.
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Röhrl in view of Adams in view of Guenschel, as applied to claim 1 above, and further in view of Skrzynski et al. Patent No. US 6,691,302 B1 (hereinafter Skrzynski).
With regard to claim 13, the combination does not explicitly teach application configuration or status queries execution through an entry point.
Skrzynski teaches the method according to claim 1, wherein via the entry point, the sensor configures the app or status queries are run (Col. 4, lines 8-14, Services modules 66-70 are user-mode processes that may be configured to start automatically at system boot time without requiring an interactive logon; they also may be controlled dynamically during run-time. Service modules 66-70 call certain base operating system services (or functions) to interact with a service controller 72; such functions may include registering a successful start-up, responding to status request, and pausing or shutting down the service; Col. 4, lines 48-52, When each service is started, its entry point function is called. The entry point function calls the RegisterServiceCtrlHandler function to register a control handler that allows the service to respond to control requests (e.g., Start Service, Stop Service, and Status Query).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Skrzynski with the teachings of Röhrl, Adams, and Guenschel in order to provide a method that teaches application configurations and status query execution performed through the entry point. The motivation for applying Skrzynski teaching with Röhrl, Adams, and Guenschel teaching is to provide a method that designates the entry point as a standardized interface for the system to perform interactions with an application such that allows for communication across a plurality of application types enabling modular system design (Skrzynski, Col. 4-Col. 5). Röhrl, Adams, Guenschel, and Skrzynski are analogous art directed towards interprogram communication. Therefore, it would have been obvious for one of ordinary skill in the art to combine Skrzynski with Röhrl, Adams, and Guenschel to teach the claimed invention in order to provide a universal communication platform to perform application-system interactions.
Claims 18 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Röhrl in view of Adams in view of Guenschel, as applied to claim 1 above, and further in view of Van Eijndhoven et al Pub. No. US 2012/0144376 A1 (hereinafter Van Eijndhoven).
With regard to claim 18, Van Eijndhoven teaches the method of claim 1, wherein the sensor provides one or more system calls for the app, wherein the app comprises system call stubs ([0087], A human-readable file with host stubs 1159 is constructed. The host stubs 1169 are small functions that are called by the annotated executable 1158 for all external calls that the linking step 1150 cannot resolve; [0338], This scheme to reduce hardware resources for implementing function calls is also applicable to implement intrinsic calls (Examiner notes: system calls). In particular, system calls to the operating system kernel are not easily handled by a hardware accelerator. Replacing such intrinsic calls by stubs (Examiner notes: system call stubs), allows routing the system call request to the boundary of the accelerator module. There, on this boundary, the request can be captured in a memory-mapped register, and an interrupt can be raised to a processor to request handling this call. The processor can perform the system call, for instance the Posix malloc( ) call, and can write the resulting value, for instance the malloc( ) result address, into the result-register at the accelerator boundary, from where the result value is passed back to the stub that issued the call).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Van Eijndhoven with the teachings of Röhrl, Adams, and Guenschel in order to provide a method that teaches system call stubs. The motivation for applying Van Eijndhoven teaching with Röhrl, Adams, and Guenschel teaching is to provide a method that allows for a stub abstraction framework to be used to extend system call functionality, such as providing the compiler user-provided functions (Van Eijndhoven, [0089]). Röhrl, Adams, Guenschel, and Van Eijndhoven are analogous art directed towards software design arrangements. Therefore, it would have been obvious for one of ordinary skill in the art to combine Van Eijndhoven with Röhrl, Adams, and Guenschel to teach the claimed invention in order to provide a framework supporting system call extension to allow for custom user-defined behavior in applications.
With regard to claim 19, Van Eijndhoven the method of claim 1, wherein a system call comprises optimized signal processing routines ([0091], Intrinsic instructions (Examiner notes: system calls), or just ‘intrinsics’ for short, can also map to a software implementation in the embedded system 4999. One useful application of software intrinsics is representing a standard software library like the well-known ‘libc’ library on Linux and other Unix-like operating systems by intrinsic instructions (Examiner notes: libc provides the interface that performs user-mode processing then internally start a system call, i.e., intrinsic instructions) … During the build step 400 a compatible implementation of the necessary standard library or libraries is linked into the embedded system 4999. Software intrinsics thus enable build step 400 to insert a highly optimized version of the intrinsics, for example an implementation that’s been manually encoded in the assembly language of the target platform)
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Van Eijndhoven with the teachings of Röhrl, Adams, and Guenschel in order to provide a method that teaches a system call comprising of optimized signal processing routines. The motivation for applying Van Eijndhoven teaching with Röhrl, Adams, and Guenschel teaching is to provide a method that allows for a user to manually implement and optimize functionality of system calls to custom components (Van Eijndhoven, [0090]). Röhrl, Adams, Guenschel, and Van Eijndhoven are analogous art directed towards software design arrangements. Therefore, it would have been obvious for one of ordinary skill in the art to combine Van Eijndhoven with Röhrl, Adams, and Guenschel to teach the claimed invention in order to provide improved performance and efficiency by using tailored, system-optimized instructions for custom components.
However, Van Eijndhoven does not explicitly teach that the system calls comprise sensor functions of query raw values and calculating measurements.
Adams teaches and sensor functions to query the current raw values and determine the calculated measured value ([0308], “s3eAccelerometerGetX(), GetY(), GetZ()” – the App Binary makes these calls to the OS abstraction API. The host environment Loader receives these calls, but the host environment has been configured so as to re-route these calls to the target device. The flow of communication and execution is the s same as for “s3eAccelerometerStart()”, noting that in these cases the function calls do return a value, which is ultimately returned to the host environment Loader and thereafter to the App Binary).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Adams with the teachings of Röhrl, Guenschel, and Van Eijndhoven in order to provide a method that teaches sensor functions that perform queries and calculations of the values used in the sensor system. The motivation for applying Adams teaching with Röhrl, Guenschel, and Van Eijndhoven teaching is to provide a method that enables system integration importing sensor-optimized header files (Adams, [0197]) as required for describing driver specific functions (Adams, [0226]). Röhrl, Adams, Guenschel, and Van Eijndhoven are analogous art directed towards design optimization. Therefore, it would have been obvious for one of ordinary skill in the art to combine Adams with Röhrl, Guenschel, and Van Eijndhoven to teach the claimed invention in order to provide function calls from sensor-optimized dependencies. This supports portability and scalability across various sensor devices enabling flexible integration and simplifies adaption to different systems.
Claims 21-22 are rejected under 35 U.S.C. 103 as being unpatentable over Röhrl in view of Adams in view of Guenschel, as applied to claim 1 and 20 respectively above, and further in view of Schönrock et al. Pub. No. US 2015/0146194 A1 (hereinafter Schönrock).
With regard to claim 21, Röhrl reasonably teaches a sensor element for detecting a measured variable of a measurement medium. However, the combination does not explicitly teach the sensor designed as an optical sensor with a light source and light receiver.
Schönrock teaches the sensor according to claim 20, wherein the sensor is designed as an optical sensor with a light source and a light receiver ([0026], To carry out the method, it is proposed that least one sensor having at least one light source and at least one receiver is provided, wherein the sensor is calibrated to a herd-specific or animal-individual white of the milk; [0019], The receiver or the receivers can successively or simultaneously relay the measurement signals corresponding to the selected wavelength of the light (Examiner notes: a light receiver) to a controller).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Schönrock with the teachings of Röhrl, Adams, and Guenschel in order to provide a system that teaches a sensor can be designed with optical sensor comprising a light source and receiver. The motivation for applying Schönrock teaching with Röhrl, Adams, and Guenschel teaching is to provide a system that allows for measurements of light to be ascertained, such that the system can quantitively assess the quality of raw materials such as raw milk (Schönrock, [0002] and [0010]). Röhrl, Adams, Guenschel, and Schönrock are analogous art directed towards embedded systems. Therefore, it would have been obvious for one of ordinary skill in the art to combine Schönrock with Röhrl, Adams, and Guenschel to teach the claimed invention in order to provide a sensor system capable of detecting and emitting light such that enables quantitative analysis of materials.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 2006/0041776 A1
teaches
Embedded Software Applications
Any inquiry concerning this communication or earlier communications from the examiner should be directed to IVAN A CASTANEDA whose telephone number is (571)272-0465. The examiner can normally be reached Monday-Friday 9:30AM-5:30PM EST.
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.
/I.A.C./Examiner, Art Unit 2195
/Aimee Li/Supervisory Patent Examiner, Art Unit 2195