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 .
Claims 1-20 are pending in this application. In the latest amendment, independent claims 1, 8, and 15 are amended. This office action is Final.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention recites a judicial exception, is directed to that judicial exception, an abstract idea, as it has not been integrated into practical application and the claims further do not recite significantly more than the judicial exception. Examiner has evaluated the claims under the framework provided in the 2019 Patent Eligibility Guidance published in the Federal Register 01/07/2019 and has provided such analysis below.
Re claims 1, 8 and 15, these claims are a method, device and product respectively wherein these claims have limitations directing to an abstract idea under the mental process wherein the limitation “performing,…based on the floating-point arithmetic method…numerical sequences” can be reasonably carried out in the human mind with the aid of pen and paper, through observation, evaluation, judgment, opinion, thus it is reasonable to identify these limitation as reciting a mental process under Prong I step 2A. Other limitations including memory, processor, instruction and “receiving…”, “acquiring…”, “acquiring…”, and “sending…” are considered as additional elements under Prong II step 2A wherein the memory, processor, and instruction are generic computer/components, or generic instructions on a computer to apply the abstract ide and the limitations of “receiving…”, “acquiring…”, “acquiring…”, and “sending…” recite insignificant extra solution activity such as gathering, displaying, updating, transmitting and storing data which does not integrate the judicial exception into a practical application. See MPEP 2106.05(d). Under step 2B, the additional elements merely recite generic computer and computer components, thus do not amount to significantly more than the judicial exception. The limitations of “receiving…”, “acquiring…”, “acquiring…”, and “sending…” the courts have identified functions such as gathering, displaying, updating, transmitting and storing data as well-understood, routine, conventional activity, thus do not amount to significantly more than the judicial exception. See MPEP 2106.05(d). Therefore, none of the additional elements recite an inventive concept, thus, the claimed invention is patent ineligible under 35 USC 101.
Re claim 2, the limitation “the floating-point arithmetic…subtraction arithmetic” can be mentally done in human mind under Prong I step 2A. Therefore, none of the additional elements recite an inventive concept, thus, the claimed invention is patent ineligible under 35 USC 101.
Step 1: In addition to claims 1, 8, and 15 analysis above, Claims 3 and 4 are directed to data processing methods and fall within the statutory category of processes; claims 10 and 11 are directed to electronic devices and fall within the statutory category of machines; claims 17 and 18 are directed to non-transitory computer readable media and fall within the statutory category of articles of manufacture. Therefore, “Are the claims to a process, machine, manufacture or composition of matter?” Yes.
In order to evaluate the Step 2A inquiry “Is the claim directed to a law of nature, a natural phenomenon or an abstract idea?” we must determine, at Step 2A Prong 1, whether the claim recites a law of nature, a natural phenomenon or an abstract idea and further whether the claim recites additional elements that integrate the judicial exception into a practical application.
Step 2A Prong 1:
Claims 3, 10, and 17: The limitations of “performing floating-point arithmetic on the corresponding floating-point numerical sequences by using a programmable circuit component in the edge switch”, as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can think about and evaluate performing floating-point arithmetic calculations. This is a mathematical calculation that takes place in the mind, even in the cases where a physical aid (e.g., pen and paper or a slide rule) are required (see MPEP § 2106.04(a)(2)(III)).
Therefore, Yes, claims 3, 10, and 17 recite judicial exceptions.
The claims have been identified to recite judicial exceptions, Step 2A Prong 2 will evaluate whether the claims are directed to the judicial exception.
Step 2A Prong 2:
In addition to claims 1, 8, and 15 analysis above, claims 3, 10, 17 depend from claims 1, 8, 15 respectively. Therefore the additional elements for each dependent claim and its independent claim have been analyzed.
Claims 3, 10, 17: The judicial exception is not integrated into a practical application. First, the claims recite the following additional elements – “by using a programmable circuit component in the edge switch” (claims 3, 10, and 17), “a processor” (claim 8), “a memory coupled to the processor and having instructions stored therein” (claim 8), “A computer program product” (claim 15), and “a non-transitory computer- readable medium and comprises machine-executable instructions” (claim 15) which is merely a recitation of a field of use/technological environment (see MPEP § 2106.05(h)) which does not integrate a judicial exception into practical application. Second, the claims recite “when executed by the processor, cause the electronic device to perform actions at an edge switch” (claim 8), and “when executed by a machine, cause the machine to execute a data processing method implemented at an edge switch” (claim 15) which is merely using a computer as a tool to apply the abstract idea (see MPEP § 2106.05(f)) which does not integrate a judicial exception into practical application. Third, the claims recite “receiving at least two data packets for floating-point arithmetic operations from at least one source device”, “acquiring corresponding floating-point numerical sequences respectively from the at least two data packets” (claims 1, 8, and 15), and “acquiring a floating-point arithmetic method from at least one data packet of the at least two data packets to determine a floating-point arithmetic result of the corresponding floating-point numerical sequences” (claims 1, 8, and 15) which is merely insignificant extra-solution data gathering and transmission activity (see MPEP § 2106.05(g)) which does not integrate a judicial exception into practical application. Further, insofar “to determine a floating-point arithmetic result” were to be positively recited, such a determination would be an abstract idea, as a person can mentally evaluate an arithmetic result of floating-point sequences. Lastly, the claims recite “and sending the floating-point arithmetic result to a target device indicated by the at least one data packet of the at least two data packets” (claims 1, 8, and 15) which is merely insignificant extra-solution data transmission activity (see MPEP § 2106.05(g)) which does not integrate a judicial exception into practical application. Examiner notes that these elements held to be merely insignificant extra-solution data gathering and data transmission will be addressed below in Step 2B as further being Well-Understood, Routine, and Conventional (WURC).
Therefore, “Do the claims recite additional elements that integrate the judicial exception into a practical application? No, these additional elements do not integrate the abstract idea into a practical application and they do not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
After having evaluating the inquires set forth in Steps 2A Prong 1 and 2, it has been concluded that claims 3, 10, and 17 not only recite a judicial exception but that the claims are directed to the judicial exception as the judicial exception has not been integrated into practical application.
Step 2B:
Claims 3, 10, and 17: The claims do not include additional elements, alone or in combination, that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements amount to no more than field of use/technological environment, using a computer as a tool to apply, and insignificant extra-solution data gathering and data transmission which do not amount to significantly more than the abstract idea. Further, the insignificant extra-solution data gathering and transmission is also WURC, see at least MPEP § 2106.05(d)(II) “The courts have recognized the following computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity. i. Receiving or transmitting data over a network” wherein receiving data packets and acquiring floating point sequences as claimed is receiving data over a network. The sending of the floating-point arithmetic result as claimed is transmitting data over a network, thus is also WURC.
Therefore, “Do the claims recite additional elements that amount to significantly more than the judicial exception? No, these additional elements, alone or in combination, do not amount to significantly more than the judicial exception.
Having concluded analysis within the provided framework, claims 3, 10, and 17 do not recite patent eligible subject matter under 35 U.S.C. § 101.
In addition to claims 1, 8, and 15 analysis above, regarding claims 4, 11, and 18, they recite additional abstract ideas of “dividing a first floating-point numerical sequence and a second floating-point numerical sequence of the corresponding floating-point numerical sequences into multiple data blocks respectively” which, as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can think about and evaluate dividing a sequence of floating point numbers into multiple blocks. Further, they recite “performing the floating-point arithmetic on a data block in the first floating-point numerical sequence and a corresponding data block in the second floating-point numerical sequence by using the programmable circuit component to determine corresponding data blocks which have been subjected to the floating-point arithmetic” which, as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can think about and evaluate performing floating-point arithmetic calculations on individual blocks of floating point numbers that have already been separated. Lastly, they recite “and combining the corresponding data blocks which have been subjected to the floating-point arithmetic to generate the floating-point arithmetic result” which, as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can think about and evaluate combining the results of floating-point arithmetic calculations on individual blocks into a final result, equivalent to summing the terms of an equation. The claims do not recite any additional elements which does not integrate a judicial exception into practical application. For the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claims 4, 11, and 18 also fail both Step 2A prong 2, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fail Step 2B as not amounting to significantly more. Therefore, claims 4, 11, and 18 do not recite patent eligible subject matter under 35 U.S.C. § 101.
Re claim 5, the limitation “sending…” recite insignificant extra solution activity such as gathering, displaying, updating, transmitting and storing data which does not integrate the judicial exception into a practical application. See MPEP 2106.05(d). Therefore, none of the additional elements recite an inventive concept, thus, the claimed invention is patent ineligible under 35 USC 101.
Re claim 6, the limitation “the at least one source device…” recite instructions to implement an abstract idea on a generic computer, or merely uses a generic computer or computer components as a tool to perform the abstract idea under Prong II step 2A. Therefore, none of the additional elements recite an inventive concept, thus, the claimed invention is patent ineligible under 35 USC 101.
Re claim 7, the limitation “the target device…” recite instructions to implement an abstract idea on a generic computer, or merely uses a generic computer or computer components as a tool to perform the abstract idea under Prong II step 2A. Therefore, none of the additional elements recite an inventive concept, thus, the claimed invention is patent ineligible under 35 USC 101.
Re claims 9, 12-14, 16 and 19-20 have similar limitations cited in claims 2 and 5-7. Thus, these claims are also rejected under the same rationale as seen in claims 2 and 5-7 above.
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-4, 6-11, 13-18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Fedorov et al. US 20200351380 A1 (Fedorov) in view of P. Cui et al. "NetFC: Enabling Accurate Floating-point Arithmetic on Programmable Switches," 2021 IEEE 29th International Conference on Network Protocols, Dallas, TX, USA, 2021, pp. 1-11, doi: 10.1109/ICNP52444.2021.9651946 (Cui) and Chua (U.S. 2009/0248769).
Regarding claim 1, Fedorov teaches A data processing method ([0001]: “According to a procedural implementation of the present disclosure, a method includes the step of receiving data associated with an Internet of Things (IoT) device and evaluating a plurality of processing factors related to the data. Based on the step of evaluating the plurality of processing factors, the method further comprises selecting where the data will be processed.”) implemented at an edge switch, ([0007]: “According to yet another embodiment, an edge device is provided. The edge device includes a message router, a processor, and a memory configured to store a program. The program, when executed, causes the processor to receive data associated with one or more IoT devices and evaluate a plurality of factors related to the processing of the data. The program also causes the processor to decide where the data will be processed based on the plurality of factors. Depending on the decision of where the data will be processed, the message router is configured to send the data to the processor for local processing or send the data to a cloud network device for remote processing.”; [0038]: “The stationary edge devices 14A may include routers, switches, multiplexers, etc.”) comprising: receiving, in an edge switch of a cloud-edge architecture, at least two data packets for floating-point arithmetic operations from at least one source device; (Fig. 8; [0094]: “FIG. 8 is a flow diagram showing an embodiment of a method 122 of processing IoT messages. In this embodiment, the method 122 includes a step of receiving data associated with an IoT device, as indicated in block 124.”; [0045]: “The IoT sensor may use the same destination address and the network may manage the mobility on its behalf by changing the forwarding tables at the edge device 14 to send its packets to the real address of its forwarding message router (e.g., using P4).”; Examiner notes, IoT data is routed in packets for processing.)
Acquiring, in the edge switch, corresponding floating-point numerical sequences respectively from the at least two data packets, each of the floating-point numerical sequences comprising a plurality of data blocks arranged in a designate order;
Acquiring, in the edge switch, a floating-point arithmetic method from at least one data packet of the at least two data packets ([0094]: “As indicated in block 126, the method 122 further includes the step of evaluating a plurality of processing functions related to the data.”) to determine a floating-point arithmetic result of the corresponding floating-point numerical sequences; ([0086]: “For example, if the network edge device 14 determines that at least a portion of IoT data obtained at the network edge device 14 is to be processed at the cloud computing device 20, the network interface 50 may be configured to receive the IoT data and store the data locally in the memory device 54 or database 56. The processor 52 may be configured to run various IoT programs (e.g., stored as IoT applications in the memory device 54) and temporarily store results in the memory device 54 and/or database 56.”)
and sending, by the edge switch, the floating-point arithmetic result to a target device ([0082]: “Depending on the decision of where the data will be processed, the message router 26 is configured to send the data to the processing device 30 for local processing or send the data to a cloud network device (e.g., cloud computing device 20) for remote processing.”; Examiner notes, Fedorov also may process some portion of the data at the edge switch and another portion at the cloud. Though it is worded by the citation like the decision must be an exclusive or, Fedorov teaches an embodiment where it is not (see at least [0086]).) indicated by the at least one data packet of the at least two data packets. (Fig. 6A, 6B, 7A, 7B; [0096]: “In addition, the step of selecting where the data will be processed may include the step of determining whether the data will be processed at a network edge device or at a cloud computing device, the cloud computing device being in communication with the network edge device via the Internet. The method may further comprise the step of utilizing a message router instantiated on the network edge device to deliver the data in an application layer message. The application layer message may be delivered to a processor of the network edge device for local processing or delivered to the cloud computing device for remote processing.”; Examiner notes, the IoT data indicates a target device where it is to be processed, see also at least [0089]-[0093] for a description of the IoT message formats cited in figures, and a detailed process for how the IoT data is able to be routed).
Fedorov does not teach comprising: receiving, in an edge switch of a cloud-edge architecture, at least two data packets for floating-point arithmetic operations from at least one source device; acquiring, in the edge switch, corresponding floating-point numerical sequences respectively from the at least two data packets, each of the floating-point numerical sequences comprising a plurality of data blocks arranged in a designated order; acquiring, in the edge switch, a floating-point arithmetic method from at least one data packet of the at least two data packets; performing, in the edge switch and based on the floating-point arithmetic method acquired from the at least one data packet, floating-point arithmetic operations on corresponding pairs of data blocks of the respective floating-point numerical sequences acquired from the respective at least two data packets, in a data block by data block pipelined manner, with an individual result of each such floating-point arithmetic operation being stored in at least one register and subsequently combined with one or more other individual results of respective other ones of the floating-point arithmetic operations in accordance with the designated order to determine a floating-point arithmetic result of the corresponding floating-point numerical sequences; and sending, by the edge switch, the floating-point arithmetic result to a target device.
However, in analogous art, Cui teaches comprising: receiving, in an edge switch of a cloud-edge architecture at least two data packets for floating-point arithmetic operations from at least one source device; (Pg. 6, Left Column: Fig. 4, 5; Pg. 7, Left Column: “The sender reads datasets and constructs floating-point operands and operators, which constitute NetFC packets to be forwarded to the switch. And the switch identifies NetFC packets and performs floating-point arithmetic operations…”)
Acquiring, in the edge switch, corresponding floating-point numerical sequences respectively from the at least two data packets, each of the floating-point numerical sequences comprising a plurality of data blocks arranged in a designated order; (Algorithm 1; Pg. 5, Right Column: “Algorithm 1 summarizes how NetFC performs floating-point addition/subtraction operations on programmable switches. First, it parses an incoming packet to obtain two operands x and y (line 1), checks their values (line 2 to 4) and projects them into logarithm space via looking up logTable (line 5).”; Examiner notes, pg. 5-6 also disclose multiplication and division floating point operations on network switches.)
Acquiring, in the edge switch, a floating-point arithmetic method from at least one data packet of the at least two data packets (Table 1 “Decision Table”; Pg. 5, Right Column: “After processing corer cases, it decides which miTable to use based on Table I.”; Examiner notes, using the decision table, the decision for the arithmetic operation is derived from the floating point sequences, therefore acquired from the data packets.) to determine a floating-point arithmetic result of the corresponding floating-point numerical sequences; (Pg. 5, Right Column: “Finally, it further looks up the selected miTable and expTable to calculate the result (line 13 to line 16). Figure 4 shows the implementation on data plane of programmable switches for addition/subtraction operations.”)
performing, in the edge switch and based on the floating-point arithmetic method acquired from the at least one data packet, floating-point arithmetic operations on corresponding pairs of data blocks of the respective floating-point numerical sequences acquired from the respective at least two data packets, in a data block by data block pipelined manner (e.g. algorithms 1 and 2 tables in page 5-6 and Figure 4-5 in page 7 wherein the operands are obtained from the input packets as x and y operands to perform FP arithmetic in pipelined manner as sequentially).
and sending, by the edge switch, the floating-point arithmetic result to a target device. (Pg. 6, Left Column: Fig. 4, 5; Pg. 10, Left Column: “By capturing packets from the inquirer’s NIC, we measured the time elapsed from the time when the query packet was sent to the time when we got the answer packet.”; Examiner notes, Fig. 4 and 5 disclose “output packet”, which is the result of the floating point operation, therefore the answer packet is the result of the floating point operation sent by the network switch).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the implementation of floating point operations on network switches in Cui with the systems and methods of Fedorov. As a result, the edge devices (which may be network switches) in Fedorov would be capable of performing floating point operations for IoT devices. Further, Fedorov would, in accordance with his cost estimation procedures, be able to determine where the floating point operations should be conducted. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, to decrease network communication overhead by offloading some proportion of the processing the cloud does for the IoT device, onto the network switches. Fedorov describes that IoT devices require low-latency end-to-end performance for needed processing, (see at least [0020], [0091]) and that edge devices may be used for some of these situations to avoid constraining cloud resources (see at least [0002]). One of the capabilities that even state-of-the-art programmable network switches lack is floating-point operations, Cui states: “Unfortunately, the computational capacity of the network is very limited, and even the state-of-the-art programmable switches (e.g. Barefoot Tofino [4]) only support simple integer arithmetic operations (e.g. addition and subtraction). This becomes a barrier to in-network acceleration of applications, because many of them often require processing sophisticated floating-point data and arithmetic operations (e.g. multiplication and division).” (Pg. 1, right column). With Cui’s teachings, Fedorov’s edge devices would have higher processing precision and capabilities, which he describes as part of the cost estimating decision (see at least [0102]). Therefore Fedorov’s edge devices would be able to accept more processing tasks, further offloading constraint on the cloud, which he states as a goal in at least [0002].
In addition, Chua discloses in Figures 1-11 an individual result of each such floating-point arithmetic operation being stored in at least one register and subsequently combined with one or more other individual results of respective other ones of the floating-point arithmetic operations in accordance with the designated order (e.g. abstract, Figured 2-10 and paragraphs [0018 and 0021-0023] wherein operands are performed in FP ALU and accumulating in sequential order).
Therefore, it would been obvious to a person having ordinary skill in the art before the effective filing date of claimed invention to add an individual result of each such floating-point arithmetic operation being stored in at least one register and subsequently combined with one or more other individual results of respective other ones of the floating-point arithmetic operations in accordance with the designated order as conceptually seen in Chua’s invention into Fedorov’s invention because it would enable to enhance the arithmetic operations.
Regarding claim 2, Fedorov in view of Cui and Chua teaches the method according to claim 1.
Fedorov in view of Cui further teaches wherein the floating-point arithmetic method comprises floating-point addition arithmetic or floating-point subtraction arithmetic. (Cui, Pg. 5, Right Column: Table 1 Decision Table; Pg. 5, Left Column: “Indeed, due to +/-, Eq. 5 has eight possible situations, which are decided by the following three conditions: 1) x > 0; 2) y > 0; 3) |x|>|y|. The detail is shown in Table I.” Examiner notes, Fedorov in view of Cui is capable of both floating point addition and subtraction).
Regarding claim 3, Fedorov in view of Cui and Chua teaches the method according to claim 1.
Fedorov in view of Cui further teaches wherein determining the floating-point arithmetic result comprises: performing floating-point arithmetic on the corresponding floating-point numerical sequences by using a programmable circuit component in the edge switch. (Cui, Pg. 6, Right Column: “In this section, we first present implementation details on programmable switches, and then introduce a few optimizations to improve the computational accuracy and reduce the overhead. We implement our NetFC on a Barefoot Tofino switch (3.2Tb/s) using P416 language”).
Regarding claim 4, Fedorov in view of Cui and Chua teaches the method according to claim 3.
Cui further teaches wherein performing floating-point arithmetic on the corresponding floating-point numerical sequences by using the programmable circuit component comprises: dividing a first floating-point numerical sequence and a second floating-point numerical sequence of the corresponding floating-point numerical sequences into multiple data blocks respectively; (Pg. 4, right column: “Our NetFC adopts a divide-and-conquer approach to address this issue. Specifically, it utilizes logarithm projection and transformation to convert the original large table into several much smaller tables together with some simple integer arithmetic operations…For example, as shown in Figure 2, two small tables are used to replace the original large arithmetic table while the total table entries are reduced from 216 × 216 to 216+216. Consequently, NetFC achieves floating-point arithmetic operations via looking up these small tables in sequence and performing some integer arithmetic operations.”; Pg. 4, right column: Fig. 2; Examiner notes, as taught earlier (pg. 5, algorithm 1) the incoming packets are “parsed” and each “operand” (floating point sequence) has its components divided and operated on respectively. See also at least Fig. 4 and Fig. 5 (pg. 6) which disclose how each operand’s components are divided and used in the arithmetic operations.) performing the floating-point arithmetic on a data block in the first floating-point numerical sequence and a corresponding data block in the second floating-point numerical sequence by using the programmable circuit component to determine corresponding data blocks which have been subjected to the floating-point arithmetic; and combining the corresponding data blocks which have been subjected to the floating-point arithmetic to generate the floating-point arithmetic result. (Pg. 5, left column, Fig. 3: “To achieve the above addition, we need to set up three tables (see Figure 3). The first table, logTable, is used to record the logarithm values of all possible keys. With this basis, it is straightforward to get the value of i and j via looking up logTable. The second table, miTable, is used to figure out the value σ(θ) = log2(1+2θ) for a given θ; we use j−i to look up miTable, and then use the result to add i. Thus we can obtain the value of i + log2(1 + 2j−i). The last table, expTable, is to compute (find out) the exponential value for a given key. With this table, we can find out the value of 2i+log2(1+2j−i) (a.k.a x + y).”; Examiner notes, see also at least (pg. 6) Fig. 4, Fig. 5, for how the results of the parsed floating point sequences are used in their own floating point operations respectively, and how the final result is deparsed (combined) before output).
Regarding claim 6, Fedorov in view of Cui and Chua teaches the method according to claim 1.
Fedorov further teaches wherein the at least one source device comprises an IoT device, (Abstract: “According to a procedural implementation of the present disclosure, a method includes the step of receiving data associated with an Internet of Things (IoT) device…”) the edge switch comprises a programmable switch, ([0007]: “According to yet another embodiment, an edge device is provided. The edge device includes a message router, a processor, and a memory configured to store a program. The program, when executed, causes the processor to receive data associated with one or more IoT devices and evaluate a plurality of factors related to the processing of the data. The program also causes the processor to decide where the data will be processed based on the plurality of factors.”; [0038]: “The stationary edge devices 14A may include routers, switches, multiplexers, etc. for enabling access to a network (e.g., the Internet 18).”) and the edge switch is configured so as to be adjacent to the IoT device. (Fig. 1; Examiner notes, IoT devices may be near edge devices (no intermediary); [0029]: “For example, the IoT applications may be instantiated on one or more edge devices (depending on where the IoT devices 12 may normally be located near the network edge) and/or on one or more cloud devices, thus allowing various devices to process the IoT data.”).
Regarding claim 7, Fedorov in view of Cui and Chua teaches the method according to claim 1.
Fedorov further teaches wherein the target device comprises a computing node (Fig. 1 – element 20; Examiner notes, compute node is a part of the internet connection with the edge devices.) configured to perform model training. ([0088]: “The reinforcement learning module 66 may include code (e.g., neural network code) for calculating future selection criteria based on historic data. More specifically, based on various processing factors (e.g., cost, availability, latency, etc.) of processing IoT data at the network edge and in the cloud and the actual results to that processing, the reinforcement learning module 66 may be configured to recognize various patterns in the data and results to determine how future selections (regarding where IoT data is processed) can be made. The respective reinforcement learning modules 44, 66 of the edge device 14 and cloud computing device 20, according to various embodiments, may be instantiated in one or both of the network edge device 14 and cloud computing device 20.”).
Regarding claim 8, it is an electronic device claim having similar limitations cited in claim 1. Thus, claim 8 is also rejected under the same rationale as cited in the rejection of claim 1 above.
Regarding claim 9, Fedorov in view of Cui and Chua teaches the electronic device according to claim 8.
Fedorov in view of Cui further teaches wherein the floating-point arithmetic method comprises floating-point addition arithmetic or floating-point subtraction arithmetic. (Cui, Pg. 5, Right Column: Table 1 Decision Table; Pg. 5, Left Column: “Indeed, due to +/-, Eq. 5 has eight possible situations, which are decided by the following three conditions: 1) x > 0; 2) y > 0; 3) |x|>|y|. The detail is shown in Table I.” Examiner notes, Fedorov in view of Cui is capable of both floating point addition and subtraction).
Regarding claim 10, Fedorov in view of Cui and Chua teaches the electronic device according to claim 8.
Fedorov in view of Cui further teaches wherein determining the floating-point arithmetic result comprises:performing floating-point arithmetic on the corresponding floating-point numerical sequences by using a programmable circuit component in the edge switch. (Cui, Pg. 6, Right Column: “In this section, we first present implementation details on programmable switches, and then introduce a few optimizations to improve the computational accuracy and reduce the overhead. We implement our NetFC on a Barefoot Tofino switch (3.2Tb/s) using P416 language”).
Regarding claim 11, Fedorov in view of Cui and Chua teaches the electronic device according to claim 10.
Cui further teaches wherein performing floating-point arithmetic on the corresponding floating-point numerical sequences by using the programmable circuit component comprises: dividing a first floating-point numerical sequence and a second floating-point numerical sequence of the corresponding floating-point numerical sequences into multiple data blocks respectively; (Pg. 4, right column: “Our NetFC adopts a divide-and-conquer approach to address this issue. Specifically, it utilizes logarithm projection and transformation to convert the original large table into several much smaller tables together with some simple integer arithmetic operations…For example, as shown in Figure 2, two small tables are used to replace the original large arithmetic table while the total table entries are reduced from 216 × 216 to 216+216. Consequently, NetFC achieves floating-point arithmetic operations via looking up these small tables in sequence and performing some integer arithmetic operations.”; Pg. 4, right column: Fig. 2; Examiner notes, as taught earlier (pg. 5, algorithm 1) the incoming packets are “parsed” and each “operand” (floating point sequence) has its components divided and operated on respectively. See also at least Fig. 4 and Fig. 5 (pg. 6) which disclose how each operand’s components are divided and used in the arithmetic operations.) performing the floating-point arithmetic on a data block in the first floating-point numerical sequence and a corresponding data block in the second floating-point numerical sequence by using the programmable circuit component to determine corresponding data blocks which have been subjected to the floating-point arithmetic; and combining the corresponding data blocks which have been subjected to the floating-point arithmetic to generate the floating-point arithmetic result. (Pg. 5, left column, Fig. 3: “To achieve the above addition, we need to set up three tables (see Figure 3). The first table, logTable, is used to record the logarithm values of all possible keys. With this basis, it is straightforward to get the value of i and j via looking up logTable. The second table, miTable, is used to figure out the value σ(θ) = log2(1+2θ) for a given θ; we use j−i to look up miTable, and then use the result to add i. Thus we can obtain the value of i + log2(1 + 2j−i). The last table, expTable, is to compute (find out) the exponential value for a given key. With this table, we can find out the value of 2i+log2(1+2j−i) (a.k.a x + y).”; Examiner notes, see also at least (pg. 6) Fig. 4, Fig. 5, for how the results of the parsed floating point sequences are used in their own floating point operations respectively, and how the final result is deparsed (combined) before output).
Regarding claim 13, Fedorov in view of Cui teaches the electronic device according to claim 8.
Fedorov further teaches wherein the at least one source device comprises an IoT device, (Abstract: “According to a procedural implementation of the present disclosure, a method includes the step of receiving data associated with an Internet of Things (IoT) device…”) the edge switch comprises a programmable switch, ([0007]: “According to yet another embodiment, an edge device is provided. The edge device includes a message router, a processor, and a memory configured to store a program. The program, when executed, causes the processor to receive data associated with one or more IoT devices and evaluate a plurality of factors related to the processing of the data. The program also causes the processor to decide where the data will be processed based on the plurality of factors.”; [0038]: “The stationary edge devices 14A may include routers, switches, multiplexers, etc. for enabling access to a network (e.g., the Internet 18).”) and the edge switch is configured so as to be adjacent to the IoT device. (Fig. 1; Examiner notes, IoT devices may be near edge devices, (no intermediary); [0029]: “For example, the IoT applications may be instantiated on one or more edge devices (depending on where the IoT devices 12 may normally be located near the network edge) and/or on one or more cloud devices, thus allowing various devices to process the IoT data.”).
Regarding claim 14, Fedorov in view of Cui and Chua teaches the electronic device according to claim 8.
Fedorov further teaches wherein the target device comprises a computing node (Fig. 1 – element 20; Examiner notes, compute node is a part of the internet connection with the edge devices.) configured to perform model training. ([0088]: “The reinforcement learning module 66 may include code (e.g., neural network code) for calculating future selection criteria based on historic data. More specifically, based on various processing factors (e.g., cost, availability, latency, etc.) of processing IoT data at the network edge and in the cloud and the actual results to that processing, the reinforcement learning module 66 may be configured to recognize various patterns in the data and results to determine how future selections (regarding where IoT data is processed) can be made. The respective reinforcement learning modules 44, 66 of the edge device 14 and cloud computing device 20, according to various embodiments, may be instantiated in one or both of the network edge device 14 and cloud computing device 20.”).
Regarding claim 15, it is a computer program product claim having similar limitations cited in claim 1. Thus, claim 15 is also rejected under the same rationale as cited in the rejection of claim 1 above.
Regarding claim 16, Fedorov in view of Cui and Chua teaches the computer program product according to claim 15.
Fedorov in view of Cui further teaches wherein the floating-point arithmetic method comprises floating-point addition arithmetic or floating-point subtraction arithmetic. (Cui, Pg. 5, Right Column: Table 1 Decision Table; Pg. 5, Left Column: “Indeed, due to +/-, Eq. 5 has eight possible situations, which are decided by the following three conditions: 1) x > 0; 2) y > 0; 3) |x|>|y|. The detail is shown in Table I.” Examiner notes, Fedorov in view of Cui is capable of both floating point addition and subtraction).
Regarding claim 17, Fedorov in view of Cui and Chua teaches the computer program product according to claim 15.
Fedorov in view of Cui further teaches wherein determining the floating-point arithmetic result comprises: performing floating-point arithmetic on the corresponding floating-point numerical sequences by using a programmable circuit component in the edge switch. (Cui, Pg. 6, Right Column: “In this section, we first present implementation details on programmable switches, and then introduce a few optimizations to improve the computational accuracy and reduce the overhead. We implement our NetFC on a Barefoot Tofino switch (3.2Tb/s) using P416 language”).
Regarding claim 18, Fedorov in view of Cui and Chua teaches the computer program product according to claim 17.
Cui further teaches wherein performing floating- point arithmetic on the corresponding floating-point numerical sequences by using the programmable circuit component comprises: dividing a first floating-point numerical sequence and a second floating-point numerical sequence of the corresponding floating-point numerical sequences into multiple data blocks respectively; (Pg. 4, right column: “Our NetFC adopts a divide-and-conquer approach to address this issue. Specifically, it utilizes logarithm projection and transformation to convert the original large table into several much smaller tables together with some simple integer arithmetic operations…For example, as shown in Figure 2, two small tables are used to replace the original large arithmetic table while the total table entries are reduced from 216 × 216 to 216+216. Consequently, NetFC achieves floating-point arithmetic operations via looking up these small tables in sequence and performing some integer arithmetic operations.”; Pg. 4, right column: Fig. 2; Examiner notes, as taught earlier (pg. 5, algorithm 1) the incoming packets are “parsed” and each “operand” (floating point sequence) has its components divided and operated on respectively. See also at least Fig. 4 and Fig. 5 (pg. 6) which disclose how each operand’s components are divided and used in the arithmetic operations.) performing the floating-point arithmetic on a data block in the first floating-point numerical sequence and a corresponding data block in the second floating-point numerical sequence by using the programmable circuit component to determine corresponding data blocks which have been subjected to the floating-point arithmetic; and combining the corresponding data blocks which have been subjected to the floating-point arithmetic to generate the floating-point arithmetic result. (Pg. 5, left column, Fig. 3: “To achieve the above addition, we need to set up three tables (see Figure 3). The first table, logTable, is used to record the logarithm values of all possible keys. With this basis, it is straightforward to get the value of i and j via looking up logTable. The second table, miTable, is used to figure out the value σ(θ) = log2(1+2θ) for a given θ; we use j−i to look up miTable, and then use the result to add i. Thus we can obtain the value of i + log2(1 + 2j−i). The last table, expTable, is to compute (find out) the exponential value for a given key. With this table, we can find out the value of 2i+log2(1+2j−i) (a.k.a x + y).”; Examiner notes, see also at least (pg. 6) Fig. 4, Fig. 5, for how the results of the parsed floating point sequences are used in their own floating point operations respectively, and how the final result is deparsed (combined) before output).
Regarding claim 20, Fedorov in view of Cui and Chua teaches the computer program product according to claim 15.
Fedorov further teaches wherein the at least one source device comprises an IoT device, (Abstract: “According to a procedural implementation of the present disclosure, a method includes the step of receiving data associated with an Internet of Things (IoT) device…”) the edge switch comprises a programmable switch, ([0007]: “According to yet another embodiment, an edge device is provided. The edge device includes a message router, a processor, and a memory configured to store a program. The program, when executed, causes the processor to receive data associated with one or more IoT devices and evaluate a plurality of factors related to the processing of the data. The program also causes the processor to decide where the data will be processed based on the plurality of factors.”; [0038]: “The stationary edge devices 14A may include routers, switches, multiplexers, etc. for enabling access to a network (e.g., the Internet 18).”) and the edge switch is configured so as to be adjacent to the IoT device. (Fig. 1; Examiner notes, IoT devices may be near edge devices (no intermediary); [0029]: “For example, the IoT applications may be instantiated on one or more edge devices (depending on where the IoT devices 12 may normally be located near the network edge) and/or on one or more cloud devices, thus allowing various devices to process the IoT data.”).
Claims 5, 12, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Fedorov et al. US 20200351380 A1 (Fedorov) in view of P. Cui et al. "NetFC: Enabling Accurate Floating-point Arithmetic on Programmable Switches," 2021 IEEE 29th International Conference on Network Protocols, Dallas, TX, USA, 2021, pp. 1-11, doi: 10.1109/ICNP52444.2021.9651946 (Cui) and Chua (U.S. 2009/0248769), further in view of Shieh et al. US 20120110393 A1 (Shieh).
Regarding claim 5, Fedorov in view of Cui and Chua teaches the method according to claim 1.
Fedorov in view of Cui teaches further comprising: sending a floating-point arithmetic service response message to the at least one source device in response to receiving a floating-point arithmetic service request message from the at least one source device (Fedorov, [0105]: “FIG. 9 shows a flow diagram of another method 132 of processing IoT messages, according to one embodiment. The method 132 includes receiving IoT-related information from an IoT device, as indicated in block 134. The IoT-related information, in some embodiments, may be received wirelessly. The step indicated in block 134 may be performed at an edge of the network by an edge device.”; Examiner notes, as previously combined, Fedorov in view of Cui can perform floating-point arithmetic on edge switches.) to inform the at least one source device that the edge switch can provide floating- point arithmetic services. (Cui, pg. 2, right column: “To address this gap, we design and implement NetFC that adopts a table-lookup method to support floating-point arithmetic operations on programmable switches.”).
Fedorov in view of Cui does not teach sending a floating-point arithmetic service response message to the at least one source device in response to receiving a floating-point arithmetic service request message from the at least one source device to inform the at least one source device that the edge switch can provide floating-point arithmetic services. (Examiner notes, Fedorov in view of Cui is aware of and does weigh the capability (including floating point capability) of the edge devices with the cloud to determine where it is most desirable to process (see at least [0102] for the cost factors and [0003] for why they are necessary to consider due to a lack of processing capabilities at the edge device). Though the determination is taught, Fedorov in view of Cui is silent about communicating that determination to the IoT device).
However, in analogous art, Shieh teaches sending a floating-point arithmetic service response message to the at least one source device in response to receiving a floating-point arithmetic service request message from the at least one source device to inform the at least one source device that the edge switch can provide floating- point arithmetic services. ([0040]: “At time 52 an AT is established between the first network switch and a second network switch. Shortly thereafter, at time 54, second network switch notifies the first network switch that that is capable of performing tunnel failover.”).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the teaching of informing a second device on a network of the capabilities of a given network switch from Shieh with the system and methods of Fedorov in view of Cui, allowing the network switches in Fedorov in view of Cui to notify an IoT device, with an established connection to the switch, that the switch is capable of performing floating point arithmetic operations. As a result, IoT devices would have a standard procedure for identifying if an edge device possessed such a capability. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, to increase the flexibility of Fedorov in view of Cui. Fedorov states in [0004] that the goal of the invention is “to provide flexibility and assistance to an application developer regarding weighing the various factors involved with processing the application data by the different devices located through the network…”. In accordance with the stated goal, the combination would provide application developers with a standardized procedure for how Fedorov in view of Cui informs IoT devices of the capabilities of the edge switches.
Regarding claim 12, Fedorov in view of Cui teaches the device according to claim 8.
Fedorov in view of Cui teaches wherein the actions further comprise: sending a floating-point arithmetic service response message to the at least one source device in response to receiving a floating-point arithmetic service request message from the at least one source device (Fedorov, [0105]: “FIG. 9 shows a flow diagram of another method 132 of processing IoT messages, according to one embodiment. The method 132 includes receiving IoT-related information from an IoT device, as indicated in block 134. The IoT-related information, in some embodiments, may be received wirelessly. The step indicated in block 134 may be performed at an edge of the network by an edge device.”; Examiner notes, as previously combined, Fedorov in view of Cui can perform floating-point arithmetic on edge switches.) to inform the at least one source device that the edge switch can provide floating- point arithmetic services. (Cui, pg. 2, right column: “To address this gap, we design and implement NetFC that adopts a table-lookup method to support floating-point arithmetic operations on programmable switches.”).
Fedorov in view of Cui does not teach sending a floating-point arithmetic service response message to the at least one source device in response to receiving a floating-point arithmetic service request message from the at least one source device to inform the at least one source device that the edge switch can provide floating- point arithmetic services. (Examiner notes, Fedorov in view of Cui is aware of and does weigh the capability (including floating point capability) of the edge devices with the cloud to determine where it is most desirable to process (see at least [0102] for the cost factors and [0003] for why they are necessary to consider due to a lack of processing capabilities at the edge device). Though the determination is taught, Fedorov in view of Cui is silent about communicating that determination to the IoT device).
However, in analogous art, Shieh teaches sending a floating-point arithmetic service response message to the at least one source device in response to receiving a floating-point arithmetic service request message from the at least one source device to inform the at least one source device that the edge switch can provide floating- point arithmetic services. ([0040]: “At time 52 an AT is established between the first network switch and a second network switch. Shortly thereafter, at time 54, second network switch notifies the first network switch that that is capable of performing tunnel failover.”).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the teaching of informing a second device on a network of the capabilities of a given network switch from Shieh with the system and methods of Fedorov in view of Cui, allowing the network switches in Fedorov in view of Cui to notify an IoT device, with an established connection to the switch, that the switch is capable of performing floating point arithmetic operations. As a result, IoT devices would have a standard procedure for identifying if an edge device possessed such a capability. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, to increase the flexibility of Fedorov in view of Cui. Fedorov states in [0004] that the goal of the invention is “to provide flexibility and assistance to an application developer regarding weighing the various factors involved with processing the application data by the different devices located through the network…”. In accordance with the stated goal, the combination would provide application developers with a standardized procedure for how Fedorov in view of Cui informs IoT devices of the capabilities of the edge switches.
Regarding claim 19, Fedorov in view of Cui and Chua teaches the computer program product according to claim 15.
Fedorov in view of Cui teaches further comprising: sending a floating-point arithmetic service response message to the at least one source device in response to receiving a floating-point arithmetic service request message from the at least one source device (Fedorov, [0105]: “FIG. 9 shows a flow diagram of another method 132 of processing IoT messages, according to one embodiment. The method 132 includes receiving IoT-related information from an IoT device, as indicated in block 134. The IoT-related information, in some embodiments, may be received wirelessly. The step indicated in block 134 may be performed at an edge of the network by an edge device.”) to inform the at least one source device that the edge switch can provide floating- point arithmetic services. (Cui, pg. 2, right column: “To address this gap, we design and implement NetFC that adopts a table-lookup method to support floating-point arithmetic operations on programmable switches.”).
Fedorov in view of Cui does not teach sending a floating-point arithmetic service response message to the at least one source device in response to receiving a floating-point arithmetic service request message from the at least one source device to inform the at least one source device that the edge switch can provide floating- point arithmetic services. (Examiner notes, Fedorov in view of Cui is aware of and does weigh the capability (including floating point capability) of the edge devices with the cloud to determine where it is most desirable to process (see at least [0102] for the cost factors and [0003] for why they are necessary to consider due to a lack of processing capabilities at the edge device). Though the determination is taught, Fedorov in view of Cui is silent about communicating that determination to the IoT device).
However, in analogous art, Shieh teaches sending a floating-point arithmetic service response message to the at least one source device in response to receiving a floating-point arithmetic service request message from the at least one source device to inform the at least one source device that the edge switch can provide floating- point arithmetic services. ([0040]: “At time 52 an AT is established between the first network switch and a second network switch. Shortly thereafter, at time 54, second network switch notifies the first network switch that that is capable of performing tunnel failover.”).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the teaching of informing a second device on a network of the capabilities of a given network switch from Shieh with the system and methods of Fedorov in view of Cui, allowing the network switches in Fedorov in view of Cui to notify an IoT device, with an established connection to the switch, that the switch is capable of performing floating point arithmetic operations. As a result, IoT devices would have a standard procedure for identifying if an edge device possessed such a capability. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, to increase the flexibility of Fedorov in view of Cui. Fedorov states in [0004] that the goal of the invention is “to provide flexibility and assistance to an application developer regarding weighing the various factors involved with processing the application data by the different devices located through the network…”. In accordance with the stated goal, the combination would provide application developers with a standardized procedure for how Fedorov in view of Cui informs IoT devices of the capabilities of the edge switches.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1-20 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.
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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Chat C Do whose telephone number is (571)272-3721. The examiner can normally be reached {M - Th} 4:30am - 2:30pm.
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, Dede Zecher can be reached at 571-272-0800. 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.
/Chat C Do/Supervisory Patent Examiner, Art Unit 2193