DETAILED ACTION
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 Amendment
Claims 1-7 and 9-15 are pending. Claims 1-2, 9 and 13-15 are currently amended. Claim 8 is canceled.
Applicant’s amendments to the claims will overcome the claim objections, 101 rejections and some 112(b) rejections previously set forth in the Non-Final Office Action mailed 04/03/2026.
Response to Arguments
Applicant's arguments filed 07/06/2026 have been fully considered but they are not persuasive.
Applicant argues on pages 10-12 “… A data processing unit is a component that is well known to those skilled in the art. As stated in the MPEP, "Claim terms are typically given their ordinary and customary meaning as understood by one of ordinary skill in the pertinent art." See MPEP § 2111.01. Simply put, a data processing unit is a programmable processor. More specifically, it is a specialized processor designed to offload and accelerate data-centric tasks, freeing up central processing units to process application-specific workloads. Those skilled in the field of process automation technology know what transducers are and they know that they can include processors. They also know that a procedure refers to a named block of code that can accept input arguments and return output values. It is used to perform specific tasks or operations within a program. An app is a piece of software designed to perform a particular function… A data processing unit is a component that is well known to those skilled in the art. As stated in the MPEP, and also above, "Claim terms are typically given their ordinary and customary meaning as understood by one of ordinary skill in the pertinent art." See MPEP §Response t
2111.01. Simply put, a data processing unit is a programmable processor. More specifically, it is a specialized processor designed to offload and accelerate data-centric tasks, freeing up central processing units to process application-specific workloads. Those skilled in the field of process automation technology know what transducers are and they know that they can include processors. They also know that a procedure refers to a named block of code that can accept input arguments and return output values. It is used to perform specific tasks or operations within a program. An app is a piece of software designed to perform a particular function.
Applicant respectfully submits the rejection of the claims under 35 U.S.C. 112(a) is overcome and requests the rejection be withdrawn.,” the examiner respectfully disagrees for the following reasons below:
Applicant argues the data processing unit is a programmable processor or specialized processor, however, the specification is void and does not disclose the data processing unit as a programmable processor or specialized processor. The specification does not disclose a programmable processor or specialized processor at all. The specification is not clear what the data processing unit is/consist of or which particular structure performs the claimed functions. Therefore, the rejections under 112(b) & (a) still stands.
Applicant argues on page 14 “…The Examiner treats a generic target device as a "measuring transducer," but that is not well supported unless the claim is interpreted extremely broadly. Because claim 1 expressly says "measuring transducer of process automation technology," it should be asserted that Russello does not disclose or suggest that environment. Rohrl's sensor checks value documents, e.g., banknotes, identity cards, tickets, and similar documents. It is a sensor, but not a process-automation measuring transducer. It also solves a different problem: simplifying software/adaptation-data updates and license transfer when replacing sensors. Russello's security policies can drive decisions to allow, deny, modify, or kill system call invocations. But the claims recite specific authorization matrices for specific relationships: " thread <-+ system call, - process <-+ app function/thread availability, process <-+ assigned app thread. The Office Action does not identify a specific Russello data structure corresponding to these matrices. It relies on broad policy/process/thread/system-call disclosures and repeats them for all three matrices.,” thee examiner respectfully disagrees for the following reasons below:
Applicant argues the examiner treats the measuring transducer as a generic target device; however, the specification and claims disclose the measuring transducer as a transmitter or sensor, executing processes such as receiving and executing apps. Russello discloses a target device being a smartphone, table, or any other programming device with an operating system capable of executing applications (Russello, page 3, paragraphs 0029-0032) which is equivalent to the argued limitation.
Applicant argues the Office Action does not identify a data structure in Russello to correspond with the matrices, however, Russello discloses monitoring applications on the target device by intercepting system calls that processes and threads perform during execution of an application based on a policy. Each system call is associated with a thread & process and each process run multiple threads (Russello, page 9, paragraphs 0168 & 0170, page 10, paragraph 0180, page 15, paragraph 0261, page 25, paragraph 0389-0392, page 26, paragraph 0395 and pages 26-27, paragraphs 0400-0412 & 0422-0423). The examiner would also like to point out the claims only requires at least one mapping not all three. Therefore, Russello teaches the argues limitations.
Applicant argues on pages 15-16 “…Consequently, while Russello mentions conventional operating systems, it does not disclose or suggest the use of a real-time operating system, which is fundamentally characterized by guaranteed timing behavior. The cited systems are therefore not capable of being interpreted as RTOS in the technical sense required by the claims.,” the examiner respectfully disagrees for the following reasons below:
Russello discloses an operating system capable of executing applications and the application execution is in real-time (Russello, page 3, paragraph 0029 and page 28, paragraph 0442) which is equivalent to the argued limitation. Applicant’s argues the operating system functionalities of real-time, however, the claims does not provide any functionalities of the operating system. The claims only states the OS operates in real-time without the operating system being linked to any claim limitations.
Applicant argues on pages 16 “For at least the foregoing reasons, Applicant respectfully submits that independent claims 1 and 13-15 is patentable over Russello and Rohrl because neither Russello nor Rohrl, taken either separately or in combination, discloses, teaches or suggests all elements of claims 1 and 13-15. Therefore, the rejection of claims 1 and 13-15 under 35 U.S.C. § 103 as being obvious in view of Russello and Rohrl is overcome and should be withdrawn. Consequently, Applicant respectfully requests withdrawal of the rejection of claims 1 and 13-15 and allowance of the same. Claims 2-12 depend either directly or indirectly from independent claims 1 and 13-15 and are submitted to be patentable for at least the reasons supporting the patentability of their base claims 1 and 13-15. Therefore, Applicant respectfully requests withdrawal of the rejection of claims 2-12 and allowance of the same.,” the examiner has shown how the independent claims are not allowable and therefore these arguments are considered moot.
Claim Interpretation
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
Claim limitations “a data processing unit configured to execute a procedure … and execute an app” (claim 13) invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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, 2, 7-10 and 13-15 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.
Claim 13 limitations “a data processing unit configured to execute a procedure … and execute an app” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. The specification is devoid of adequate structure to perform the claim function. There is no disclosure of any particular structure, either explicitly or inherently to perform the functions because the applicant’s specification does not describe a particular structure and does not provide enough description for one of ordinary skill in the art to understand which structure perform the claim functions. The specification paragraphs 0061, 0087 & 0090 discloses the measuring transducer including a data processing unit but the specification is not clear what the data processing unit is/consist of or which particular structure performs the claimed functions.
Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
Any claim not specifically addressed above is being rejected as incorporating the deficiencies of a claim upon which it depends.
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claim 13 is rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for pre-AIA the inventor(s), at the time the application was filed, had possession of the claimed invention. As described above, the disclosure does not provide adequate structure to perform the claim functions of “a data processing unit configured to execute a procedure … and execute an app” invokes”. The specification does not demonstrate that applicant has made an invention that achieves the claimed function because the invention is not described with sufficient details that one of ordinary skill in the art can reasonably conclude that the inventor has position of claimed invention.
Any claim not specifically addressed above is being rejected as incorporating the deficiencies of a claim upon which it depends.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
Claim(s) 1-7 and 9-15 are rejected under 35 U.S.C. 103 as being unpatentable over Russello (US Pub No. 2015/0332043) in view of Rohrl et al. (US Pub No. 2014/0147030).
Regarding independent claim 1, Russello teaches a procedure for executing an application app on a measuring transducer of process automation technology, wherein the measuring transducer is designed to receive and store apps Russello, page 2, paragraph 0026, page 3, paragraphs 0029 & 0036, page 9, paragraph 0170 and page 26, paragraph 0395; target device executing applications), wherein the measuring transducer is designed to execute one or more processes (Russello, page 2, paragraph 0026, page 3, paragraphs 0029 & 0036, page 7, paragraphs 0115-0118, page 9, paragraph 0170, page 26, paragraph 0395; target device executing applications/processes), the procedure comprising steps: providing system calls from the measuring transducer (Russello, page 2, paragraph 0026, page 3, paragraphs 0029 & 0036, page 7, paragraphs 0115-0118, page 9, paragraph 0170, page 26, paragraph 0395; target device executing applications/processes; monitoring system calls); transmitting the app to the measuring transducer if the app is not yet located on the measuring transducer, wherein the app comprises at least one program code with at least one app function, and generates and executes one or more threads at runtime, wherein each app function is assigned to one or more threads (Russello, page 7, paragraphs 0115-0118, page 9, paragraphs 0168 & 0170, page 25, paragraph 0389-0392, page 26, paragraph 0395 and pages 26-27, paragraphs 0400-0412 & 0422; executing application; process ID, thread ID, package name and system call info), wherein it is determined which system calls each thread is authorized to use, and wherein it is determined which thread is executed in which process (Russello, page 9, paragraphs 0168 & 0170, page 10, paragraph 0180, page 15, paragraph 0261, page 25, paragraph 0389-0392, page 26, paragraph 0395 and pages 26-27, paragraphs 0400-0412 & 0422-0423; monitor application running on target device & all system calls, thread, processes based on policy) and executing the app on the measuring transducer (Russello, page 9, paragraphs 0168 & 0170, page 25, paragraph 0389-0392, page 26, paragraph 0395 and pages 26-27, paragraphs 0400-0412 & 0422; target device executing application); and at least one of the procedure steps a), b), or c), comprising a) checking at runtime by means of a first authorization matrix whether the thread actually only uses the system call(s) to which the thread is authorized: if authorization is present, an execution of the system call takes place, and if no authorization is present, the app is terminated (Russello, page 9, paragraphs 0168 & 0170, page 10, paragraph 0180, page 15, paragraph 0261, page 25, paragraph 0389-0392, page 26, paragraph 0395 and pages 26-27, paragraphs 0400-0412 & 0422-0423; monitor application running on target device & all system calls, thread, processes based on policy; killing application when security action is indicated); b) checking at runtime by means of a second authorization matrix whether a process only calls those functions that a thread makes available to it: if authorization is present, an execution of the function takes place, and if no authorization is present, treatment as a firmware implementation error in the host takes place (Russello, page 9, paragraphs 0168 & 0170, page 10, paragraph 0180, page 15, paragraph 0261, page 25, paragraph 0389-0392, page 26, paragraph 0395 and pages 26-27, paragraphs 0400-0412 & 0422-0423; monitor application running on target device & all system calls, thread, processes based on policy; killing application when security action is indicated); c) checking at runtime by means of a third authorization matrix whether a process only executes the threads assigned thereto: if authorization is present, the thread is executed by the process, and if no authorization is present, treatment as a firmware implementation error in the host takes place (Russello, page 9, paragraphs 0168 & 0170, page 10, paragraph 0180, page 15, paragraph 0261, page 25, paragraph 0389-0392, page 26, paragraph 0395 and pages 26-27, paragraphs 0400-0412 & 0422-0423; monitor application running on target device & all system calls, thread, processes based on policy; killing application when security action is indicated); wherein the operating system of the measuring transducer is designed as a real-time operating system (Russello, page 3, paragraph 0029 and page 28, paragraph 0442).
Russello teaches each and every claim limitation but does not explicitly teach wherein the firmware of the measuring transducer is designed to receive and store apps.
Rohrl teaches wherein the firmware of the measuring transducer is designed to receive and store apps (Rohrl, page 1, paragraph 0010 and page 2, paragraph 0016; firmware for loading software and applications).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify Russello with the teachings of Rohrl for the device to include firmware for loading software and applications to provide the advantage of improving the update of sensors (Rohrl, page 1, paragraph 0004).
Regarding claim 2, Russello in view of Rohrl teaches the procedure wherein a system call can be called by more than one thread and a shared resources are jointly protected against parallel access by a suitable protection mechanism (Russello, page 7, paragraphs 0115-0118, page 8, paragraph 0143, page 9, paragraphs 0168 & 0170, page 25, paragraph 0389-0392, page 26, paragraph 0395 and pages 26-27, paragraphs 0400-0412 & 0422).
Regarding claim 3, Russello in view of Rohrl teaches the procedure wherein a system call and threads calling it are mapped to a single process (Russello, page 7, paragraphs 0115-0118, page 8, paragraph 0143, page 9, paragraphs 0168 & 0170, page 25, paragraph 0389-0392, page 26, paragraph 0395 and pages 26-27, paragraphs 0400-0412 & 0422).
Regarding claim 4, Russello in view of Rohrl teaches the procedure wherein the step of checking at runtime by means of the first authorization matrix whether the thread actually only uses the system call(s) to which the thread is authorized comprises one or more of the following measures: per system call: a bit vector with length equal to the number of threads, set bit i means thread is allowed to call the relevant system call; per thread: a bit vector with length equal to the number of system calls, set bit i means thread is allowed to call system call; per system call: sorted list of unique thread identifiers i that are allowed to call the system call, wherein by means of a binary search it is checked whether the system call is allowed to be called by a thread; per thread: sorted list of unique system call identifiers i that a thread is allowed to call, wherein by means of a binary search it is checked whether the thread is allowed to call a system call; per system call: balanced binary search tree of unique thread identifiers i, corresponding to the threads that are allowed to call system calls; per thread: balanced binary search tree of unique system call identifiers i, corresponding to the system calls that the thread is allowed to call; per system call: hash table of unique thread identifiers i, corresponding to the threads that are allowed to call system call; per thread: hash table of unique system call identifiers i, corresponding to the system calls that the thread is allowed to call (Russello, page 9, paragraphs 0168 & 0170, page 10, paragraph 0180, page 15, paragraph 0261, page 25, paragraph 0389-0392, page 26, paragraph 0395 and pages 26-27, paragraphs 0400-0412 & 0422-0423; monitor application running on target device & all system calls, thread, processes based on policy; killing application when security action is indicated).
Regarding claim 5, Russello in view of Rohrl teaches the procedure wherein the step of checking at runtime by means of a second authorization matrix whether a process only calls those functions that a thread makes available to it comprises one or more of the following measures: per app function: a bit vector with length equal to the number of threads, set bit i means thread is allowed to call the relevant app function; per thread: a bit vector with length equal to the number of app functions, set bit i means thread is allowed to call app function; per app function: sorted list of unique thread identifiers that are allowed to call the app function, wherein by means of a binary search it is checked whether the app function is allowed to be called by a thread in that the binary search searches for the thread identifier of the calling thread in the sorted list of unique thread identifiers; per thread: sorted list of unique app function identifiers that a thread is allowed to call, wherein by means of a binary search it is checked whether the thread is allowed to call an app function in that the binary search searches for the app function identifier of the app function to be called in the sorted list of unique app function identifiers; per app function: balanced binary search tree of unique thread identifiers that are allowed to call app function; per thread: balanced binary search tree of unique app function identifiers that are allowed to call the thread; per app function: hash table of unique thread identifiers that are allowed to call app function; per thread: hash table of unique identifiers of app functions that the thread is allowed to call (Russello, page 9, paragraphs 0168 & 0170, page 10, paragraph 0180, page 15, paragraph 0261, page 25, paragraph 0389-0392, page 26, paragraph 0395 and pages 26-27, paragraphs 0400-0412 & 0422-0423; monitor application running on target device & all system calls, thread, processes based on policy; killing application when security action is indicated).
Regarding claim 6, Russello in view of Rohrl teaches the procedure wherein the step of checking at runtime by means of the third authorization matrix whether a process executes only the threads assigned thereto comprises one or more of the following measures: per process: a bit vector with length equal to the number of threads, set bit i means process is allowed to execute the app thread; per thread: a bit vector with length equal to the number of processes, set bit i means thread is allowed to be executed by process; per process: sorted list of unique thread identifiers that the process is allowed to call, wherein by means of a binary search it is checked whether the process is allowed to execute the thread in that the binary search searches for the thread identifier of the thread to be executed in the sorted list of unique thread identifiers; per thread: sorted list of unique process identifiers from which a thread is allowed to be executed, wherein by means of a binary search it is checked whether the thread is allowed to be executed by a process in that the binary search searches for the process identifier of the executing process in the sorted list of unique process identifiers; per process: balanced binary search tree of unique thread identifiers that process is allowed to execute; per thread: balanced binary search tree of unique process identifiers that are allowed to execute thread; per process: hash table of unique thread identifiers that the process is allowed to execute; per thread: hash table of unique identifiers of processes that are allowed to execute the thread (Russello, page 9, paragraphs 0168 & 0170, page 10, paragraph 0180, page 15, paragraph 0261, page 25, paragraph 0389-0392, page 26, paragraph 0395 and pages 26-27, paragraphs 0400-0412 & 0422-0423; monitor application running on target device & all system calls, thread, processes based on policy; killing application when security action is indicated).
Regarding claim 7, Russello in view of Rohrl teaches each and every claim limitation of claim 1, however, Rohrl teaches the procedure wherein the firmware of the measuring transducer comprises the first, second and/or third authorization matrix Rohrl teaches wherein the firmware of the measuring transducer is designed to receive and store apps (Rohrl, page 1, paragraph 0010 and page 2, paragraph 0016; firmware for loading software and applications and sensor once loaded the sensor checks).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify Russello with the teachings of Rohrl for the device to include firmware for loading software and applications to provide the advantage of improving the update of sensors (Rohrl, page 1, paragraph 0004).
Regarding claim 9, Russello in view of Rohrl teaches the procedure wherein the program code further comprises at least: a main logic; and asystem call stubs, by means of which functions in a basic system are called (Russello, page 19, paragraph 0290).
Regarding claim 10, Russello in view of Rohrl teaches the procedure wherein the program code further comprises at least: a main logic; and the system call stubs, by means of which functions in the basic system are called (Russello, page 1, paragraph 0004 and page 23, paragraph 0358).
Regarding claim 11, Russello in view of Rohrl teaches the procedure wherein the virtual machine is designed as a just-in-time compiler, ahead-of-time compiler, hypervisor or a combination thereof, and the app is present in a corresponding format on the basic system (Russello, page 1, paragraph 0004 and page 23, paragraph 0358).
Regarding claim 12, Russello in view of Rohrl teaches the procedure wherein the program code further comprises at least: a main logic; and the system call stubs, by means of which functions in the basic system are called (Russello, page 1, paragraphs 0004-0006, page 20, paragraph 0316 and page 23, paragraph 0358).
Regarding independent claim 13, Russello teaches a measuring transducer, comprising: a data processing unit configured to execute a procedure; and a memory; wherein the data processing unit is further configured to execute an application app on a measuring transducer of process automation technology, wherein the measuring transducer is designed to receive and store apps (Russello, page 2, paragraph 0026, page 3, paragraphs 0029 & 0036, page 9, paragraph 0170 and page 26, paragraph 0395; target device executing applications), wherein the measuring transducer is designed to execute one or more processes (Russello, page 2, paragraph 0026, page 3, paragraphs 0029 & 0036, page 7, paragraphs 0115-0118, page 9, paragraph 0170, page 26, paragraph 0395; target device executing applications/processes), the procedure comprising steps: providing system calls from the measuring transducer (Russello, page 2, paragraph 0026, page 3, paragraphs 0029 & 0036, page 7, paragraphs 0115-0118, page 9, paragraph 0170, page 26, paragraph 0395; target device executing applications/processes; monitoring system calls); transmitting the app to the measuring transducer if the app is not yet located on the measuring transducer, wherein the app comprises at least one program code with at least one app function, and generates and executes one or more threads at runtime, wherein each app function is assigned to one or more threads (Russello, page 7, paragraphs 0115-0118, page 9, paragraphs 0168 & 0170, page 25, paragraph 0389-0392, page 26, paragraph 0395 and pages 26-27, paragraphs 0400-0412 & 0422; executing application; process ID, thread ID, package name and system call info), wherein it is determined which system calls each thread is authorized to use, and wherein it is determined which thread is executed in which process (Russello, page 9, paragraphs 0168 & 0170, page 10, paragraph 0180, page 15, paragraph 0261, page 25, paragraph 0389-0392, page 26, paragraph 0395 and pages 26-27, paragraphs 0400-0412 & 0422-0423; monitor application running on target device & all system calls, thread, processes based on policy) and executing the app on the measuring transducer (Russello, page 9, paragraphs 0168 & 0170, page 25, paragraph 0389-0392, page 26, paragraph 0395 and pages 26-27, paragraphs 0400-0412 & 0422; target device executing application); and at least one of the procedure steps a), b), or c), comprising a) checking at runtime by means of a first authorization matrix whether the thread actually only uses the system call(s) to which the thread is authorized: if authorization is present, an execution of the system call takes place, and if no authorization is present, the app is terminated (Russello, page 9, paragraphs 0168 & 0170, page 10, paragraph 0180, page 15, paragraph 0261, page 25, paragraph 0389-0392, page 26, paragraph 0395 and pages 26-27, paragraphs 0400-0412 & 0422-0423; monitor application running on target device & all system calls, thread, processes based on policy; killing application when security action is indicated); b) checking at runtime by means of a second authorization matrix whether a process only calls those functions that a thread makes available to it: if authorization is present, an execution of the function takes place, and if no authorization is present, treatment as a firmware implementation error in a host takes place (Russello, page 9, paragraphs 0168 & 0170, page 10, paragraph 0180, page 15, paragraph 0261, page 25, paragraph 0389-0392, page 26, paragraph 0395 and pages 26-27, paragraphs 0400-0412 & 0422-0423; monitor application running on target device & all system calls, thread, processes based on policy; killing application when security action is indicated); c) checking at runtime by means of a third authorization matrix whether a process only executes the threads assigned thereto: if authorization is present, the thread is executed by the process, and if no authorization is present, treatment as a firmware implementation error in the host takes place (Russello, page 9, paragraphs 0168 & 0170, page 10, paragraph 0180, page 15, paragraph 0261, page 25, paragraph 0389-0392, page 26, paragraph 0395 and pages 26-27, paragraphs 0400-0412 & 0422-0423; monitor application running on target device & all system calls, thread, processes based on policy; killing application when security action is indicated); wherein the operating system of the measuring transducer is designed as a real-time operating system (Russello, page 3, paragraph 0029 and page 28, paragraph 0442).
Russello teaches each and every claim limitation but does not explicitly teach wherein the firmware of the measuring transducer is designed to receive and store apps.
Rohrl teaches wherein the firmware of the measuring transducer is designed to receive and store apps (Rohrl, page 1, paragraph 0010 and page 2, paragraph 0016; firmware for loading software and applications).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify Russello with the teachings of Rohrl for the device to include firmware for loading software and applications to provide the advantage of improving the update of sensors (Rohrl, page 1, paragraph 0004).
Regarding independent claim 14, Russello teaches a computer program product comprising a non-transitory computer readable medium storing program instructions which, when executed on a measuring transducer, cause the measuring transducer to execute the following procedure: wherein the measuring transducer is designed to receive and store apps Russello, page 2, paragraph 0026, page 3, paragraphs 0029 & 0036, page 9, paragraph 0170 and page 26, paragraph 0395; target device executing applications), wherein the measuring transducer is designed to execute one or more processes (Russello, page 2, paragraph 0026, page 3, paragraphs 0029 & 0036, page 7, paragraphs 0115-0118, page 9, paragraph 0170, page 26, paragraph 0395; target device executing applications/processes), the procedure comprising the steps: providing system calls from the measuring transducer (Russello, page 2, paragraph 0026, page 3, paragraphs 0029 & 0036, page 7, paragraphs 0115-0118, page 9, paragraph 0170, page 26, paragraph 0395; target device executing applications/processes; monitoring system calls); transmitting the app to the measuring transducer if the app is not yet located on the measuring transducer, wherein the app comprises at least program code with at least one app function, and generates and executes one or more threads at runtime, wherein each app function is assigned to one or more threads (Russello, page 7, paragraphs 0115-0118, page 9, paragraphs 0168 & 0170, page 25, paragraph 0389-0392, page 26, paragraph 0395 and pages 26-27, paragraphs 0400-0412 & 0422; executing application; process ID, thread ID, package name and system call info), wherein it is determined which system calls each thread is authorized to use, and wherein it is determined which thread is executed in which process (Russello, page 9, paragraphs 0168 & 0170, page 10, paragraph 0180, page 15, paragraph 0261, page 25, paragraph 0389-0392, page 26, paragraph 0395 and pages 26-27, paragraphs 0400-0412 & 0422-0423; monitor application running on target device & all system calls, thread, processes based on policy) and executing the app on the measuring transducer (Russello, page 9, paragraphs 0168 & 0170, page 25, paragraph 0389-0392, page 26, paragraph 0395 and pages 26-27, paragraphs 0400-0412 & 0422; target device executing application); and at least one of the procedure steps a), b), or c), comprising a) checking at runtime by means of a first authorization matrix whether the thread actually only uses the system call(s) to which the thread is authorized: if authorization is present, an execution of the system call takes place, and if no authorization is present, the app is terminated (Russello, page 9, paragraphs 0168 & 0170, page 10, paragraph 0180, page 15, paragraph 0261, page 25, paragraph 0389-0392, page 26, paragraph 0395 and pages 26-27, paragraphs 0400-0412 & 0422-0423; monitor application running on target device & all system calls, thread, processes based on policy; killing application when security action is indicated); b) checking at runtime by means of a second authorization matrix whether a process only calls those functions that a thread makes available to it: if authorization is present, an execution of the function takes place, and if no authorization is present, treatment as a firmware implementation error in a host takes place (Russello, page 9, paragraphs 0168 & 0170, page 10, paragraph 0180, page 15, paragraph 0261, page 25, paragraph 0389-0392, page 26, paragraph 0395 and pages 26-27, paragraphs 0400-0412 & 0422-0423; monitor application running on target device & all system calls, thread, processes based on policy; killing application when security action is indicated); c) checking at runtime by means of a third authorization matrix whether a process only executes the threads assigned thereto: if authorization is present, the thread is executed by the process, and if no authorization is present, treatment as a firmware implementation error in the host takes place (Russello, page 9, paragraphs 0168 & 0170, page 10, paragraph 0180, page 15, paragraph 0261, page 25, paragraph 0389-0392, page 26, paragraph 0395 and pages 26-27, paragraphs 0400-0412 & 0422-0423; monitor application running on target device & all system calls, thread, processes based on policy; killing application when security action is indicated); wherein the operating system of the measuring transducer is designed as a real-time operating system (Russello, page 3, paragraph 0029 and page 28, paragraph 0442).
Russello teaches each and every claim limitation but does not explicitly teach wherein the firmware of the measuring transducer is designed to receive and store apps.
Rohrl teaches wherein the firmware of the measuring transducer is designed to receive and store apps (Rohrl, page 1, paragraph 0010 and page 2, paragraph 0016; firmware for loading software and applications).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify Russello with the teachings of Rohrl for the device to include firmware for loading software and applications to provide the advantage of improving the update of sensors (Rohrl, page 1, paragraph 0004).
Regarding independent claim 15, Russello teaches a non-transitory computer-readable medium storing a computer program for executing the following procedure: wherein the measuring transducer is designed to receive and store applications apps Russello, page 2, paragraph 0026, page 3, paragraphs 0029 & 0036, page 9, paragraph 0170 and page 26, paragraph 0395; target device executing applications), wherein the measuring transducer is designed to execute one or more processes (Russello, page 2, paragraph 0026, page 3, paragraphs 0029 & 0036, page 7, paragraphs 0115-0118, page 9, paragraph 0170, page 26, paragraph 0395; target device executing applications/processes), the procedure comprising the steps: providing system calls from the measuring transducer (Russello, page 2, paragraph 0026, page 3, paragraphs 0029 & 0036, page 7, paragraphs 0115-0118, page 9, paragraph 0170, page 26, paragraph 0395; target device executing applications/processes; monitoring system calls); transmitting the app to the measuring transducer if the app is not yet located on the measuring transducer, wherein the app comprises at least program code with at least one app function, and generates and executes one or more threads at runtime, wherein each app function is assigned to one or more threads (Russello, page 7, paragraphs 0115-0118, page 9, paragraphs 0168 & 0170, page 25, paragraph 0389-0392, page 26, paragraph 0395 and pages 26-27, paragraphs 0400-0412 & 0422; executing application; process ID, thread ID, package name and system call info), wherein it is determined which system calls each thread is authorized to use, and wherein it is determined which thread is executed in which process (Russello, page 9, paragraphs 0168 & 0170, page 10, paragraph 0180, page 15, paragraph 0261, page 25, paragraph 0389-0392, page 26, paragraph 0395 and pages 26-27, paragraphs 0400-0412 & 0422-0423; monitor application running on target device & all system calls, thread, processes based on policy) and executing the app on the measuring transducer (Russello, page 9, paragraphs 0168 & 0170, page 25, paragraph 0389-0392, page 26, paragraph 0395 and pages 26-27, paragraphs 0400-0412 & 0422; target device executing application); and at least one of the procedure steps a), b), or c), comprising a) checking at runtime by means of a first authorization matrix whether the thread actually only uses the system call(s) to which the thread is authorized: if authorization is present, an execution of the system call takes place, and if no authorization is present, the app is terminated (Russello, page 9, paragraphs 0168 & 0170, page 10, paragraph 0180, page 15, paragraph 0261, page 25, paragraph 0389-0392, page 26, paragraph 0395 and pages 26-27, paragraphs 0400-0412 & 0422-0423; monitor application running on target device & all system calls, thread, processes based on policy; killing application when security action is indicated); b) checking at runtime by means of a second authorization matrix whether a process only calls those functions that a thread makes available to it: if authorization is present, an execution of the function takes place, and if no authorization is present, treatment as a firmware implementation error in the host takes place (Russello, page 9, paragraphs 0168 & 0170, page 10, paragraph 0180, page 15, paragraph 0261, page 25, paragraph 0389-0392, page 26, paragraph 0395 and pages 26-27, paragraphs 0400-0412 & 0422-0423; monitor application running on target device & all system calls, thread, processes based on policy; killing application when security action is indicated); c) checking at runtime by means of a third authorization matrix whether a process only executes the threads assigned thereto: if authorization is present, the thread is executed by the process, and if no authorization is present, treatment as a firmware implementation error in a host takes place (Russello, page 9, paragraphs 0168 & 0170, page 10, paragraph 0180, page 15, paragraph 0261, page 25, paragraph 0389-0392, page 26, paragraph 0395 and pages 26-27, paragraphs 0400-0412 & 0422-0423; monitor application running on target device & all system calls, thread, processes based on policy; killing application when security action is indicated); wherein the operating system of the measuring transducer is designed as a real-time operating system (Russello, page 3, paragraph 0029 and page 28, paragraph 0442).
Russello teaches each and every claim limitation but does not explicitly teach wherein the firmware of the measuring transducer is designed to receive and store apps.
Rohrl teaches wherein the firmware of the measuring transducer is designed to receive and store apps (Rohrl, page 1, paragraph 0010 and page 2, paragraph 0016; firmware for loading software and applications).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify Russello with the teachings of Rohrl for the device to include firmware for loading software and applications to provide the advantage of improving the update of sensors (Rohrl, page 1, paragraph 0004).
Conclusion
THIS ACTION IS MADE FINAL. 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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHAQUEAL D WADE whose telephone number is (571)270-0357. The examiner can normally be reached M-F 8:00-5:00.
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, Catherine Thiaw can be reached at 571-270-1138. 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.
/SHAQUEAL D WADE-WRIGHT/Primary Examiner, Art Unit 2407
