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 .
Claims 1-17 are pending for examination.
Drawings
The drawings are objected to under 37 CFR 1.83(a) because they fail to show proper identification of reference elements of Fig. 1 as described in the specification. Fig. 1 includes elements 100, 101 and 102; however, these elements do not indicate what they represent. Any structural detail that is essential for a proper understanding of the disclosed invention should be shown in the drawing. MPEP § 608.02(d). Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Claim Objections
Claims 1 and 15 are objected to because of the following informalities:
Claims 1 and 15 recite “(100)”, “(101)” and “(102)”, which is unnecessary. It is recommended these reference numerals and its parentheses be removed.
Appropriate correction is required.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-17 rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-16 of co-pending U.S. Patent application No. 18/785,543. Although the claims at issue are not identical, they are not patentably distinct from each other because they are substantially similar in scope, recite analogous limitations, and they achieve the same overall result of arrangement of packet-based data transfer. Accordingly, the claim limitations of the present application represent obvious variation of those in the reference co-pending application.
The table below shows comparison between the instant application and the reference co-pending application. The examiner underlined the difference in claim languages (See table below). Underlined differences are obvious variants of each other. The co-pending application already recites a readout of latency and/or bandwidth specifications “for all virtual data paths.” Reading out such specifications for all virtual data paths necessarily requires obtaining the specification for each individual virtual data path. The instant application’s additional recitation that the readout is “defined separately for each virtual data path” merely makes explicit what is already implicit in the earlier claims and represents, at most, an obvious design choice. The remaining elements of the instant application do not materially alter the underlying invention and do not render the claims patentably distinct. Accordingly, the claims of the instant application are unpatentable for non-statutory obvious-type double patenting over the co-pending application.
Instant Application 18/785,550
Reference Application 18/785,543
Claim 1. A method for initialising a system arrangement for the packet-based transmission of data on up to 128 virtual data paths via a physical data channel of an automobile with deterministic latency, comprising:
a readout (100) of a provided latency specification and/or a bandwidth specification of the data channel for in each case all virtual data paths for the transmission of a bit sequence to be transmitted, wherein the readout (100) of the provided latency specification and/or the bandwidth specification is defined separately for each virtual data path;
a setting (102) of a packet length for each of the 128 data paths, taking into account four predefined packet lengths of the bit sequence, the packet length being selected (101) in each case in such a way that short packet lengths are used for short latency requirements and low available bandwidth and long packet lengths are selected for long latency requirements and high available bandwidth.
Claim 1. A method for initialising a system arrangement for the packet-based transmission of data on up to 128 virtual data paths via a physical data channel of an automobile with deterministic latency, comprising:
a readout (100) of a provided latency time specification and/or a bandwidth specification of the data channel for all virtual data paths for the transmission of a bit sequence to be transmitted;
a setting (102) of a packet length for each of the 128 data paths, taking into account four predefined packet lengths of the bit sequence, the packet length being selected (101) in each case in such a way that short packet lengths are used for short latency requirements and low available bandwidth and long packet lengths are selected for long latency requirements and high available bandwidth, ….
Claim 2. The method of claim 1, wherein the amount of overhead data is reduced by increasing the packet length.
Claim 2. The method of claim 1, wherein the amount of overhead data is reduced by increasing the packet length.
Claim 3. The method of claim 1, wherein the data to be transmitted is n * 112 bits+187.
Claim 1. …the data to be transmitted being n * 112 bits+187 bits.
Claim 4. The method of claim 1, wherein a path identifier, a sequence number, a cell type, at least one checksum, at least one user data information item and/or a further user data information item are transmitted with the bit sequence to be transmitted.
Claim 3. The method of claim 1, wherein a path identifier, a sequence number, a cell type, at least one checksum, at least one user data information item and/or a further user data information item are transmitted with the bit sequence to be transmitted.
Claim 5. The method of claim 1, wherein the overhead data is 25 or 37 bits.
Claim 4. The method of claim 1, wherein the overhead data is 25 or 37 bits.
Claim 6. The method of claim 1, wherein a stored metric is used which indicates which of the four predefined packet lengths is to be selected.
Claim 5. The method of claim 1, wherein a stored metric is used which indicates which of the four predefined packet lengths is to be selected.
Claim 7. The method of claim 6, wherein the metric designates the respective packet length and takes into account the bandwidth and/or the packet length to be transmitted.
Claim 6. The method of claim 5, wherein the metric designates the respective packet length and takes into account the bandwidth and/or the packet length to be transmitted.
Claim 8. The method of claim 1, wherein a shorter packet length is selected for a low bandwidth.
Claim 7. The method of claim 1, wherein a shorter packet length is selected for a low bandwidth.
Claim 9. The method of claim 1, wherein a longer packet length is selected for a higher bandwidth.
Claim 8. The method of claim 1, wherein a longer packet length is selected for a higher bandwidth.
Claim 10. The method of claim 1, wherein a short packet length is selected for a low number of data to be transmitted and a long packet length is used for a high number of data to be transmitted.
Claim 9. The method of claim 1, wherein a short packet length is selected for a low number of data to be transmitted and a long packet length is used for a high number of data to be transmitted.
Claim 11. The method of claim 1, wherein a stored metric is used which indicates which packet length is selected in which value range of the latency requirement and/or the available bandwidth.
Claim 10. The method of claim 1, wherein a stored metric is used which indicates which packet length is selected in which value range of the latency requirement and/or the available bandwidth.
Claim 12. The method of claim 1, wherein a stored metric is used which indicates which packet length is selected for which latency requirement and which bandwidth.
Claim 11. The method of claim 1, wherein a stored metric is used which indicates which packet length is selected for which latency requirement and which bandwidth.
Claim 13. The method of claim 1, wherein the four predefined packet lengths are 187 bits, 411 bits, 635 bits and 859 bits.
Claim 12. The method of claim 1, wherein the four predefined packet lengths are 187 bits, 411 bits, 635 bits and 859 bits.
Claim 14. The method of claim 1, wherein the physical data channel is operated either electrically or optically.
Claim 13. The method of claim 1, wherein the physical data channel is operated either electrically or optically.
Claim 15. A system arrangement for the packet-based transmission of data on up to 128 virtual data paths via a physical data channel of an automobile with deterministic latency, having:
an interface unit set up for reading out (100) a provided latency time specification and/or a bandwidth specification of the data channel for all virtual data paths for the transmission of a bit sequence to be transmitted, wherein the reading out (100) of the provided latency time specification and/or the bandwidth specification is defined separately for each virtual data path;
an initialisation unit set up for setting (102) a packet length for each of the 128 data paths, taking into account four predefined packet lengths of the bit sequence, the packet length being selected (101) in each case by means of a selection unit in such a way that short packet lengths are used for short latency requirements and low available bandwidth and long packet lengths are selected for long latency requirements and high available bandwidth.
Claim 14. A system arrangement for the packet-based transmission of data on up to 128 virtual data paths via a physical data channel of an automobile with deterministic latency, having:
an interface unit set up for reading (100) a provided latency time specification and/or a bandwidth specification of the data channel for all virtual data paths for the transmission of a bit sequence to be transmitted;
an initialisation unit set up for setting (102) a packet length for each of the 128 data paths, taking into account four predefined packet lengths of the bit sequence, the packet length being selected (101) in each case by means of a selection unit in such a way that short packet lengths are used for short latency requirements and low available bandwidth and long packet lengths are selected for long latency requirements and high available bandwidth, ….
Claim 16. A computer program product comprising instructions which, when the program is executed by at least one computer, cause the computer to perform the steps of the method of claim 1.
Claim 15. A computer program product comprising instructions which, when the program is executed by at least one computer, cause the computer to perform the steps of the method of claim 1.
Claim 17. A computer-readable storage medium comprising instructions which, when executed by at least one computer, cause the computer to perform the steps of the method of claim 1.
Claim 16. A computer-readable storage medium comprising instructions which, when executed by at least one computer, cause the computer to perform the steps of the method of claim 1.
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, 3, 5 and 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.
Claims 1 and 15 recite the limitation " the packet-based transmission" in line 1. There is insufficient antecedent basis for this limitation in the claim.
Claims 1 and 15 recites “the data channel” in line 5, it is unclear whether it refers to the “physical data channel” recites in line 2.
Claims 1 and 15 recites “the transmission” in line 5, it is unclear whether it refers to the “packet-based transmission” recites in line 1.
Claim 3 recites the limitation " the data" in line 1. There is insufficient antecedent basis for this limitation in the claim.
Claim 3 recites “the data to be transmitted is n*112 bits+187”, but the variable n is not defined. The claim does not specify what the “n” represents. Also it is unclear what the “187” represents, is it only a numerical value or 187 bits of header, parity, metadata or padding.
Claim 5 recites the limitation "the overhead" in line 1. There is insufficient antecedent basis for this limitation in the claim.
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 15-17 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claims do not fall within at least one of the four categories of patent eligible subject matter because:
Regarding Claim 15, the independent Claim 15 recites “A system arrangement….having: an interface unit…an initialisation unit…”, However, the specification fails to provide any structural description of these units and instead expressly states that the “device and units” may be implemented as process steps and that “physical components can also be provided virtually or virtualised.” (Para. 0078). The specification therefore indicates that the recited “interface unit” and “initialisation unit” do not correspond to any specific hardware structure, but rather represent abstract functional descriptions of steps performed by software. Therefore, the claim is not limited to statutory subject matter and is therefore non-statutory. As such, claim 15 is drawn to non-statutory subject matter. See MPEP § 2106.01
Regarding Claim 16, the claim recites “A computer program product comprising instructions which, when the program is executed by at least one computer…”. A computer program per se, without being embodied in a non-transitory computer-readable medium or tied to a specific machine, is considered non-statutory subject matter. Furthermore, the specification explicitly states that the “devices and units” may be implemented as process steps and that “physical components can also be provided virtually or virtualised.” (Para. 0078) indicating that the claimed “computer program product” is not limited to any physical structure or tangible medium. Therefore, the claim encompasses software instruction which do not fall within any of the four statutory categories of invention, therefore rejected under 35 U.S.C. §101.
Regarding Claim 17, the claim recites “A computer-readable storage medium comprising instructions which, when executed by at least one computer…”. The claim does not recite any structural limitation that require the medium to be a tangible, non-transitory article of manufacture. The specification explicitly states that the “devices and units” may be implemented as process steps and that “physical components can also be provided virtually or virtualised.” (Para. 0078) indicating that the claimed medium is not limited to a physical storage device but may encompass virtual, non-physical, transitory implementation. Non-statutory embodiments such as signals, carrier waves, or other transient forms of information transmission, which are excluded from patent eligibility. Because the claim fails to require a tangible, non-transitory computer-readable storage medium and instead encompasses abstract or transitory forms of software, claim 17 does not fall within any of the four statutory categories of invention, therefore rejected under 35 U.S.C. §101.
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.
Claims 1, 6-10, and 13-17 are rejected under 35 U.S.C. 103 as being unpatentable over US 2012/0182892 (Frazier et al.) in view of CN 112838886 (Wang et al.), and further in view of US 2008/0159150 (Ansari).
Regarding Claim 1, Frazier teaches a method for initialising a system arrangement for the packet-based transmission of data via a physical data channel of an automobile with deterministic latency ([¶ 0015], a method for low-latency networking. …latency requirements of traffic to be communicated along a network path comprising one or more Ethernet links may be determined. A maximum size of Ethernet frames utilized for communicating the traffic may be determined based on the latency requirements. The maximum size of the Ethernet frames may be determined based on a data rate of one or more Ethernet links along the network path. The maximum size of the Ethernet frames may be determined to be a first, smaller value when the traffic pertains to automobile control and/or safety systems. [¶ 0016] The network device may packetize traffic to be communicated on the network path into Ethernet frames. [Fig. 1, ¶ 0020], the devices 102.sub.1-102.sub.3 and 104 may exchange packetized information over the links 114.sub.1-114.sub.4. The communications may, for example, be in adherence with one or more Ethernet physical layer standards. The communications may comprise, for example, communication of data packetized in accordance with Ethernet standards. Latency of a network link may be influenced by the maximum size of messages transmitted on that link), comprising:
a readout (100) of a provided latency specification and/or a bandwidth specification of the data channel for in each paths for the transmission of a bit sequence to be transmitted, wherein the readout (100) of the provided latency specification and/or the bandwidth specification is defined separately for each virtual data path ([¶¶ 0015, 0045], latency requirements of traffic to be communicated along a network path comprising one or more links may be determined. … determine …a data rate of one or more Ethernet links along the network path. [¶ 0026], Latency requirements of traffic may be determined based on, for example, inspection of the traffic, and/or based on a program generating or otherwise associated with the traffic. [¶ 0046], The determined maximum Ethernet frame size may be based on latency requirements of traffic to be communicated on the network path. The maximum size of the Ethernet frames may be based on a data rate associated with one or more links of the network path);
a setting (102) of a packet length for each data paths, …the packet length being selected (101) in each case in such a way that short packet lengths are used for short latency requirements and low available bandwidth and long packet lengths are selected for long latency requirements and high available bandwidth ([Fig. 1, ¶ 0040], device 102.sub.1, has traffic to communicate to a remote network device such as the device 102.sub.2 or the device 102.sub.3. …the device 102.sub.1 may determine the latency sensitivity of the traffic to be communicated. For example, if the traffic is destined for device 102.sub.2 (via links 114.sub.1 and 114.sub.3), the device 102.sub.1 may determine that the traffic requires low latency. Conversely, if the traffic is destined for device 102.sub.3 (via links 114.sub.2 and 114.sub.4), the device 102.sub.1 may determine that the traffic may be tolerant of higher latency. …the device 102.sub.1 may determine a maximum message size corresponding to the determined latency requirements. The device 102.sub.1 may determine to utilize a first, smaller maximum message size for lower-latency traffic and determine to utilize a second, larger maximum message size for latency-tolerant traffic. [Fig. 1, ¶ 0042], when the device 102.sub.1 has traffic to communicate over a reserved network path, such as the path 112 or the path 110. …the device 102.sub.1 may determine the latency sensitivity of the traffic to be communicated. For example, if the traffic pertains to vehicle control and/or safety systems, the device 102.sub.1 may determine that the traffic requires low latency. Conversely, if the traffic is for entertainment purposes, the device 102.sub.1 may determine that the traffic may be tolerant of higher latency. …the device 102.sub.1 may determine a maximum message size for communicating the traffic based on the latency requirements and based on the resources available along the network path. For example, if all links along the path are high-speed, then a larger maximum message size may be utilized whereas a smaller maximum message size may be necessary if one or more links along the path are lower speed).
Although, Frazier teaches traffic to be communicated along a network path comprising one or more Ethernet links, however, Frazier does not explicitly teach, Wang teaches transmission of data on up to 128 virtual data paths via a physical data channel ([Page 9], the virtual channel identifier is used to specify the address to which the bitstream data is sent in the data frame format. The virtual channel identifier data bit size is determined according to the number of virtual channel paths and is characterized by binary numbers. The virtual channel is a plurality of parallel 'virtual' paths established on a physical channel, which enables the upper layer data streams of a plurality of users to share the same physical channel, and each virtual channel has own service requirement and service level. Note: When the claim recites “up to 128 virtual data paths”, it defines an upper bound, not a required quantity. Therefore, a plurality of parallel 'virtual' paths established on a physical channel describes a system operates within the claimed range, because any plurality of paths is necessarily less than or equal to 128 unless the reference sates otherwise).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Wang’s teaching of establishing a plurality of parallel virtual paths over a single physical channel to Frazier’s communication of traffic along a network path comprising one or more Ethernet links because such incorporation would have been a predictable design choice to improve throughput, increase channel utilization, and support differentiated traffic handling across the same physical channel.
Frazier in view of Wang do not explicitly teach, however, Ansari teaches a setting (102) of a packet length for each data paths, taking into account four predefined packet lengths of the bit sequence ([¶¶ 0024-0025] As depicted in FIG. 1, each link 120 has an associated MTU size. Specifically, links 120.sub.1-120.sub.8 have MTU sizes of 1500, 1476, 576, 1070, 898, 868, 1200, and 1208, respectively. As described herein, the MTU size of a link may depend upon the underlying data link layer technology or physical layer technology by which packets are conveyed over the link. …a plurality of MTU tables 112 store MTU information, including MTU size information. MTU tables 112 store MTU information on a per-link basis).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Ansari’s teaching of storing and using multiple MTU values in a MTU table on a per-link basis to the combine teachings of Frazier and Wang because such incorporation would have been a predictable design choice to improve flexibility, interoperability, and performance across varying link condition. The modification would merely involve selecting a packet length from a known set of predefined sizes, which is a routine optimization yielding no unexpected result.
Regarding Claim 6, Frazier in view of Wang do not explicitly teach, however, Ansari teaches the method of claim 1, wherein a stored metric is used which indicates which of the four predefined packet lengths is to be selected ([¶¶ 0024-0025], As depicted in FIG. 1, each link 120 has an associated MTU size. Specifically, links 120.sub.1-120.sub.8 have MTU sizes of 1500, 1476, 576, 1070, 898, 868, 1200, and 1208, respectively. …include a plurality of MTU tables 112.sub.1-112.sub.5, respectively. The MTU tables 112 store MTU information, including MTU size information. MTU tables 112 store MTU information on a per-link basis. each MTU table 112 includes an entry for each link 120 in communication network 100, where the entry for a given link 120 is the MTU size for that link 120).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Ansari’s teaching of storing and using multiple MTU values in a MTU table on a per-link basis to the combine teachings of Frazier and Wang because such incorporation would have been a predictable design choice to improve flexibility, interoperability, and performance across varying link condition.
Regarding Claim 7, Frazier in view of Wang do not explicitly teach, however, Ansari teaches the method of claim 6, wherein the metric designates the respective packet length and takes into account the bandwidth and/or the packet length to be transmitted ([¶ 0025]include a plurality of MTU tables. The MTU tables store MTU information, including MTU size information [i.e., respective packet length]. MTU tables store MTU information on a per-link basis [i.e., packet length to be transmitted for each link]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Ansari’s teaching of storing and using multiple MTU values in a MTU table on a per-link basis to the combine teachings of Frazier and Wang because such incorporation would have been a predictable design choice to improve flexibility, interoperability, and performance across varying link condition.
Regarding Claim 8, Frazier teaches the method of claim 1, wherein a shorter packet length is selected for a low bandwidth(if the traffic is destined for device 102.sub.2 (via links 114.sub.1 and 114.sub.3), the device 102.sub.1 may determine that the traffic requires low latency. …determine to utilize a first, smaller maximum message size for lower-latency traffic. … a smaller maximum message size may be necessary if one or more links along the path are lower speed).
Regarding Claim 9, Frazier teaches the method of claim 1, wherein a longer packet length is selected for a higher bandwidth ([¶¶ 0040, 0042] if the traffic is destined for device 102.sub.3 (via links 114.sub.2 and 114.sub.4), the device 102.sub.1 may determine that the traffic may be tolerant of higher latency. …the device 102.sub.1 may determine a maximum message size corresponding to the determined latency requirements. … if all links along the path are high-speed, then a larger maximum message size may be utilized.
Regarding Claim 10, Frazier teaches the method of claim 1, wherein a short packet length is selected for a low number of data to be transmitted and a long packet length is used for a high number of data to be transmitted ([Fig. 1, ¶ 0040], device 102.sub.1, has traffic to communicate to a remote network device such as the device 102.sub.2 or the device 102.sub.3. …the device 102.sub.1 may determine the latency sensitivity of the traffic to be communicated. For example, if the traffic is destined for device 102.sub.2 (via links 114.sub.1 and 114.sub.3), the device 102.sub.1 may determine that the traffic requires low latency. Conversely, if the traffic is destined for device 102.sub.3 (via links 114.sub.2 and 114.sub.4), the device 102.sub.1 may determine that the traffic may be tolerant of higher latency. …the device 102.sub.1 may determine a maximum message size corresponding to the determined latency requirements. The device 102.sub.1 may determine to utilize a first, smaller maximum message size for lower-latency traffic and determine to utilize a second, larger maximum message size for latency-tolerant traffic. [Fig. 1, ¶ 0042], when the device 102.sub.1 has traffic to communicate over a reserved network path, such as the path 112 or the path 110. …the device 102.sub.1 may determine the latency sensitivity of the traffic to be communicated. For example, if the traffic pertains to vehicle control and/or safety systems, the device 102.sub.1 may determine that the traffic requires low latency. Conversely, if the traffic is for entertainment purposes, the device 102.sub.1 may determine that the traffic may be tolerant of higher latency. …the device 102.sub.1 may determine a maximum message size for communicating the traffic based on the latency requirements and based on the resources available along the network path. For example, if all links along the path are high-speed, then a larger maximum message size may be utilized whereas a smaller maximum message size may be necessary if one or more links along the path are lower speed).
Regarding Claim 13, Frazier in view of Wang do not explicitly teach, however, Ansari teaches the method of claim 1, wherein the four predefined packet lengths are 187 bits, 411 bits, 635 bits and 859 bits ([¶¶ 0024-0025], discloses a packet transmission system in which each link has an associated MTU size stored in MTU table (e.g., links 120.sub.1-120.sub.8 have MTU sizes of 1500, 1476, 576, 1070, 898, 868, 1200, and 1208). Ansari further teaches that the MTU values are stored and used by routers to govern packet transmission over respective links. Note: selecting 187/411/635/859 bits instead of MTU-derived values would have been an obvious implementation choice. Under KSR Int’s Co. v. Teleflex Inc. 550 U.S. 398 (2007), where a claimed combination merely applied known technique and design choice to achieve predictable results, such modification constitutes obviousness; here, substituting or expressing MTU-based packet size control as discrete selectable packet lengths, including the claimed values, would have been a predictable implementation choice within the skill of the art, yielding no more than expected results).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Ansari’s teaching of maintaining multiple MTU values in a MTU table for different links to the combine teachings of Frazier and Wang because such incorporation would have been a routine design choice based on implementation needs, performance requirements, or protocol constraints. Selecting specific packet length from a known set of multiple predefined sizes represents nothing more than optimization of known parameter, which is considered obvious under KSR because it yields predictable results.
Regarding Claim 14, Frazier teaches The method of claim 1, wherein the physical data channel is operated either electrically or optically ([0015], The maximum size of the Ethernet frames may be determined based on a data rate of one or more Ethernet links along the network path).
Regarding Claims 15, 16 and 17, the claim limitations are identical and/or equivalent in scope to claim 1, therefore Claims 15-16 and 17 are rejected under the same rationale as claim 1. Examiner further notes, Frazier also teaches a computer program product comprising instructions and a computer-readable storage medium comprising instructions, as required in Claims 16 and 17. (See Para. 0047)
Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over combination of Frazier-Wang-Ansari, and further in view of US 6404776 (Voois et al.).
Regarding Claim 2, Frazier in view of Wang and Ansari do not explicitly teach, however, Voois teaches the method of claim 1, wherein the amount of overhead data is reduced by increasing the packet length ([C.16:L.58-63] reducing the packet size can increase the total overhead involved in the transmission, thus reducing the bandwidth available on the communication channel. It is therefore desirable to transmit the largest packets that are appropriate for the transmission error rate to reduce overhead and conserve bandwidth).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Voois’s explicit teaching that smaller packets increase total overhead and reduce effective bandwidth, and that therefore larger packets should be used when appropriate to reduce overhead and conserve bandwidth to the combine teachings of Frazier-Wang-Ansari because such incorporation would have been motivated to setup larger packet length when link condition permit in order to reduce overhead and improve bandwidth efficiency.
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over combination of Frazier-Wang-Ansari, and further in view of RU 2335845 (Kurseren et al.).
Regarding Claim 3, Frazier in view of Wang and Ansari do not explicitly teach, however, Kurseren teaches the method of claim 1, wherein the data to be transmitted is n * 112 bits+187 ([Page 14, First para.] when the video multiplexing encoder receives a block (two-dimensional array) of quantized transform coefficients, it finds the number N.sub.c of nonzero coefficients in the array, and the indication of this number is transmitted to the decoder in a stream of 635 bits. …the number N.sub.c is encoded with a variable length code before transmission. Note: Kurseren teaches transmitting an indication in a stream of 635 bits. It is well known in the art that transmitted data streams are structured as a plurality of fixed-size data units combined with fixed overhead bits, such as headers, checksums, or encoding overhead. It would have been obvious to a person of ordinary skill in the art to structure the transmitted data stream using such known techniques, resulting in a total data size expressible as n × (unit size) + constant overhead. The specific values (e.g., 112 bits and 187 bits) represent result-effective variables, and selecting values that yield a total of 635 bits (e.g., n = 4) would have been within routine optimization).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Kurseren’s teaching of specific bitstream lengths are selected in practice to efficiently encode and transmit data to the combine teachings of Frazier-Wang-Ansari because such incorporation would have allowed the system to produce target transmission sizes, such as 635 bits, by appropriate .
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over combination of Frazier-Wang-Ansari, and further in view of US 6098188 (Kalmanek et al.).
Regarding Claim 4, Frazier in view of Wang and Ansari do not explicitly teach, however, Kalmanek teaches the method of claim 1, wherein a path identifier, a sequence number, a cell type, at least one checksum, at least one user data information item and/or a further user data information item are transmitted with the bit sequence to be transmitted ([C.4:L.15-21], encapsulates the packet to create an augmented set of ordered signals known as a "frame." …a frame is a variable-length set of signals that advantageously comprises, in order, the following six fields: (1) a "user-data" field, (2) a "padding" field, (3) a "CRC-data" field, (4) a "sequence-identifier" field, (5) a "user-data-length" filed and (6) a "CRC-trailer" field).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Kalmanek’s teachings of encapsulating a payload into a frame with multiple fields including user-data, padding, CRC data, a sequence identifier, a user data length field, and a CRC trailer to the combine teachings of Frazier-Wang-Ansari because such incorporation would predictably enhance robustness, enable per-path identification, support sequencing, and ensure integrity of transmitted data.
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over combination of Frazier-Wang-Ansari, and further in view of US 20120290574 (Isaacson et al.).
Regarding Claim 5, Frazier in view of Wang and Ansari do not explicitly teach, however, Isaacson teaches the method of claim 1, wherein the overhead data is 25 or 37 bits ([¶ 0148], The table 57 in FIG. 18 shows the total compression overhead as being 25 bits, which brings the compressed size of the data stream to 508 bits, or 483 bits plus 25 bits. Since, Isaacson explicitly teaches that compression overhead is 25 bits, which is added to the data stream (e.g., 483 bits+25 bits), thereby disclosing overhead data of 25 bits).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Isaacson’s explicit teaching that compression overhead may be fixed number of bits, such as 25 bits overhead to the combine teachings of Frazier-Wang-Ansari because such incorporation would have been motivated to adopt specific, predetermined overhead values as a routine design choice to achieve predictable and consistent packet sizing.
Claims 11 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over combination of Frazier-Wang-Ansari, and further in view of US 20050220093 (Chen et al.).
Regarding Claim 11, while Ansari teaches MTU table that store MTU information on a per-link basis, however, Frazier in view of Wang and Ansari do not explicitly teach, Chen teaches the method of claim 1, wherein a stored metric is used which indicates which packet length is selected in which value range of the latency requirement and/or the available bandwidth ([¶¶ 0061-0064] obtain a packet length from a table of pre-stored packet length. Packet lengths are updated based on the latency and/or router packet bandwidth usage. the packet length table is initially configured to default values that conform to acceptable end-to-end latency requirements. Chen teaches teach a functional relationship between packet length, latency requirements, and available bandwidth, and further teach that this relationship is implemented via a stored mapping (table). Such a table constitutes a stored metric that indicates which packet length is selected for given operating conditions.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Chen’s explicit teaching of using a pre-stored table that stores packet lengths and the table adjusted based on latency and/or router packet bandwidth usage to the combine teachings of Frazier-Wang-Ansari, because such incorporation enables efficient real-time packet processing through table lookup, reduces computational overhead and allows flexible system configuration and optimization by updating stored values rather than calculating the packet size.
Regarding Claim 12, while Ansari teaches MTU table that store MTU information on a per-link basis, however, Frazier in view of Wang and Ansari do not explicitly teach, Chen teaches the method of claim 1, wherein a stored metric is used which indicates which packet length is selected for which latency requirement and which bandwidth ([¶¶ 0061-0064] obtain a packet length from a table of pre-stored packet length. Packet lengths are updated based on the latency and/or router packet bandwidth usage. the packet length table is initially configured to default values that conform to acceptable end-to-end latency requirements. Chen teaches teach a functional relationship between packet length, latency requirements, and available bandwidth, and further teach that this relationship is implemented via a stored mapping (table). Such a table constitutes a stored metric that indicates which packet length is selected for given operating conditions.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Chen’s explicit teaching of using a pre-stored table that stores packet lengths and the table adjusted based on latency and/or router packet bandwidth usage to the combine teachings of Frazier-Wang-Ansari, because such incorporation enables efficient real-time packet processing through table lookup, reduces computational overhead and allows flexible system configuration and optimization by updating stored values rather than calculating the packet size.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MOHAMMAD YOUSUF A MIAN whose telephone number is (571)272-9206. The examiner can normally be reached Monday-Friday 9am-5: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, ARIO ETIENNE can be reached at 571-272-4001. 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.
/MOHAMMAD YOUSUF A. MIAN/Examiner, Art Unit 2457
/ARIO ETIENNE/Supervisory Patent Examiner, Art Unit 2457
Prosecution Insights