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 .
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Information Disclosure Statement
The art submitted by Applicant has been considered by the Examiner in the same manner as other documents in Office search files are considered while conducting a search of the prior art in a proper field of search. Some of the art has been imported into SEARCH and filtered using keywords and other criteria in an attempt to determine if it is relevant. The art which cannot be imported into SEARCH has been considered by reviewing summary information, such as the title and abstract, in an attempt to determine if it is relevant.
Claim Rejections - 35 USC § 112 – Scope of Enablement
The following is a quotation of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), first paragraph:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, because the specification, while being enabling for a limited scope based on the teachings in the application, does not reasonably provide enablement for the full scope recited in the claims. The specification does not enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the invention commensurate in scope with these claims.
MPEP 2164.08 states: “The Federal Circuit has repeatedly held that ‘the specification must teach those skilled in the art how to make and use the full scope of the claimed invention without ‘undue experimentation’.” In re Wright, 999 F.2d 1557, 1561, 27 USPQ2d 1510, 1513 (Fed. Cir. 1993).
Teachings of the Application and Scope of the Claims.
In the paragraph spanning pages 4-5, the application teaches that, in the prior art, containers could not be configured for clients with different bit rates.
By means of the described operation, a client is mapped to a corresponding container having a structure with a fixed length, and the containers may correspondingly carry clients within different bit rate ranges according to different configured sizes of overhead areas, therefore, the solution provided in the embodiments of the present disclosure may solve the technical problem in the related art that containers cannot be configured for clients with different bit rates so as to compromise between overhead transmission periods and bandwidth utilization, and may achieve the effect of satisfying the requirements for the transmission periods of overhead fields with high real-time demands without increasing the transfer frequency for the overhead that has high real-time requirements.
The present invention addresses this by using particular overhead sizes, using particular numbers of overhead sections, and using different overhead structures in a particular ways for different bit rates. See the application on page 6, which discusses the parts of the container including basic overhead units and extended overhead units:
The overhead area of the small granularity container (equivalent to the container in the embodiments of the present disclosure) into two parts: basic overhead unit(s) and extended overhead unit(s). The basic overhead unit is used for transmitting a set of all overheads for end-to-end monitoring of the client. The extended overhead unit is used for transmitting at least one overhead field having a high requirement for real-time performance. The at least one overhead field is a subset of end-to-end monitoring overheads, and includes one or more of a trail trace identifier overhead, an automatic protection switching overhead channel, and a small granularity container status indication overhead. The small granularity container status indication overhead is used for indicating a status of the small granularity container, wherein the status includes a normal status and a maintenance status, and the maintenance status includes an alarm indication signal, an open connection indication signal, and a locked indication signal.
In particular, the application teaches the invention is used with a container having an overhead with basic overhead units and extended overhead units, with each carrying particular information.
The application at page 7 teaches how to calculate the maximum length of the container.
In an exemplary embodiment, an overhead field with a high real-time requirement and a corresponding transmission period are determined, and the number of required basic units is determined based on the number of overhead bytes carried by the basic overhead unit and the size of the overhead field, the transmission period of the basic unit is determined, and a minimum transmission period X of the basic unit therein is taken as a transmission period of the basic unit of the small granularity container. For example, when one basic overhead unit is used to transmit one byte of an automatic protection switching protocol, and the automatic protection switching protocol includes four bytes, four basic overhead units are needed to complete the transmission of the automatic protection switching protocol. If the transmission of the automatic protection switching protocol needs to be completed within 3ms, the transmission period of the basic overhead unit is 3ms/4 = 0.75ms. Assuming that the minimum bit rate of the clients in the high bit rate range is Y, the maximum length L of the structure of the small granularity container is determined based on the values of X and Y according to a formula L = Y * X. Based on this, the structure of the small granularity container can be determined.
This calculation is L = Y * X. This calculation requires knowing Y and X, where Y is the minimum bit rate of the clients in the high bit rate range, and X is the minimum transmission period. To discover X, the time in which the transmission of the automatic protection switching protocol needs to be completed is divided by the number of bytes needed to complete the transmission of the automatic protection switching protocol for the container (e.g., in the example above: 3ms/4).
The calculation of L produces the maximum length of the structure, but it does not set the overhead area for different bit rates. Pages 9-11 illustrate examples in which the overhead is modified based on different bit rates of the client. In the paragraph beginning on page 9, line 12, the first step is “clients are divided into three groups according to bit rate ranges”, high bit rate group, medium bit rate group, and low bit rate group. In the paragraph beginning on line 19, the total number of basic overhead units/bytes is calculated (4 bytes in this example) and the time in which the transmission needs to be completed (i.e., the minimum transmission period of the basic overhead) is calculated (1ms in this example). In the paragraph beginning on line 25, these values are used to calculate the transmission period of each basic overhead unit (0.25ms in this example). In the paragraph spanning pages 9-10, the maximum length of the frame structure of the container is calculated (9375 bytes, in this example), and the length of the container is calculated (9280 bytes in this example). This provides the bytes available for overhead and payload. On page 10, first full paragraph, the transmission period is calculated by dividing the length of the container (converted to bits) by the bit rate (9280*8/500=0.148ms). In this example, the transmission period (0.148ms) is less than the minimum transmission period (0.25ms) calculated above, meaning that the overhead does not need to be changed for this bit rate. This is illustrated in FIG. 4.
PNG
media_image1.png
166
664
media_image1.png
Greyscale
This arrangement has only a basic overhead area and no extended overhead areas.
In the next paragraph, a lower bit rage (100 Mbps) example is given in which the transmission period is greater than the minimum transmission period.
In operation 4, for a client within a medium bit rate range, a lowest bit rate of the client is 100Mbps, and if the small granularity container determined in operation 3 is directly used, the transmission period of the protection switching-related overhead is 9280*8/100 ≈ 0.7424ms, which cannot satisfy requirements. To address this issue, for the small granularity container of the client within the medium bit rate range, the small granularity container may be constructed by evenly inserting three extended overhead units, i.e., the length of the small granularity container is 9280 bytes, including one 16-byte basic overhead unit and three 16-byte extended overhead units, wherein the overhead units are spaced by 2304 payload bytes, and the overhead ratio is 16*4/9280 = 0.69%.
In this case, the overhead needs to be changed because the transmission period is greater than the minimum transmission period. In such a situation, the application teaches to add three evenly spaced extended overhead units (see the paragraph above). This is illustrated in FIG. 5.
PNG
media_image2.png
162
662
media_image2.png
Greyscale
In this arrangement there is one basic overhead unit and three extended overhead units, all of which are evenly spaced with equal payload areas.
The bottom half of page 10 and the top of page 11 discussed another example with a lower bit rate. This is illustrated in FIG. 6.
PNG
media_image3.png
148
654
media_image3.png
Greyscale
In this example, additional, evenly spaced extended header areas are added.
Beginning on page 13, another example is presented. In the paragraph in the middle of page 13, the structure of the overhead area is described:
The overhead area of the small granularity container (equivalent to the container in the embodiments of the present disclosure) into two parts: basic overhead unit(s) and extended overhead unit(s). The basic overhead unit is used for transmitting a set of all overheads for end-to-end monitoring of the client. The extended overhead unit is used for transmitting at least one overhead field having a high requirement for real-time performance. The at least one overhead field is a subset of end-to-end monitoring overheads, and includes one or more of a trail trace identifier overhead, an automatic protection switching overhead channel, and a small granularity container status indication overhead. The small granularity container status indication overhead is used for indicating a status of the small granularity container, wherein the status includes a normal status and a maintenance status, and the maintenance status includes an alarm indication signal, an open connection indication signal, and a locked indication signal.
In the paragraph spanning pages 13-14, the construction of the overhead is discussed:
The clients that need to be supported are divided according to different bit rate ranges. A maximum bit rate in a high bit rate range is a maximum bit rate of the clients that need to be supported. The structure of the small granularity container is determined according to the high bit rate. The structure of the small granularity container includes an overhead area and a payload area. The overhead area includes a basic overhead unit. The structure of the small granularity container is able to satisfy the transmission period of the overhead with a high real-time requirement. After the design of the structure of the small granularity container of the high bit rate client is completed, for clients in other bit rate ranges, a fixed number of extended overhead units are evenly configured in the structure of the small granularity container as required, so as to ensure that the structure of the small granularity container carrying the client with the lowest bit rate in the bit rate range is able to complete overhead transmission with high real-time requirements within a fixed time period X.
The length of the container L is calculated at the top of page 14:
In an exemplary embodiment, a maximum length of the container is determined as L=Y*X, wherein Y is a minimum bit rate corresponding to the client within a target bit rate range, and X is a minimum transmission period of the basic overhead unit of the container.
The calculation of X is taught on page 7, as discussed above. X is the minimum transmission period, and calculating it requires defining characteristics of the system, including bytes in the automatic protection switching protocol, and the time to complete the automatic protection switching protocol.
In the middle of page 14 it is taught that one or more extended overhead units are used for bit rate ranges other than (less than) the maximum bit rate range:
In an exemplary embodiment, when the different bit rate ranges include N bit rate ranges, a client in a first bit rate range of the N bit rate ranges may be configured with a basic overhead unit with a fixed size, wherein the first bit rate range is a maximum bit rate range of the N bit rate ranges. A basic overhead unit with a fixed size, a payload area, and one or more extended overhead units may be configured for a client in a bit rate range other than the first bit rate range among the N bit rate ranges.
This is done when the transmission period of the basic overhead unit is more than the time period requirements. See the example on pages 9-11 of the application where this calculation is illustrated. It also teaches that the extended overhead units are evenly spaced. See the paragraph spanning pages 14-15:
It should be noted that, when the fixed number of the extended overhead units is determined, the fixed number of extended overhead units need to be evenly distributed in the container. For example, when the length of the container is 9280 bytes, the container is constructed by using one basic overhead unit of 16 bytes and three extended overhead units of 16 bytes. In order to ensure the usage effect, the three extended overhead units may be spaced by 2304 payload bytes, that is, the three extended overhead units are evenly inserted into the current container to construct a new container structure.
In summary, the application teaches using particular overhead sizes and structures in a particular way for different bit rates, including making calculations based on the bit rate and other factors.
In contrast to the teachings of the application, claim 1 recites:
1. A client mapping method, comprising:
mapping a client into a corresponding container, wherein the container is a structure with a fixed length and comprises an overhead area and a payload area;
and containers that carry clients within different bit rate ranges have different overhead areas.
This broadly recites “an overhead area” and does not limit the scope to any particular overhead size or structure, and does not require any of the steps taught in the application for determining how to modify the overhead of the container for clients with different bit rates. As a result, this claim has a scope that includes mapping a client with any bit rate into any container, with any overhead structure, as long different overhead areas are used with different bit rates. This scope does not appear to be supported by the application.
In summary, the application teaches a complex and particular series of functions/steps for mapping a client into containers wherein clients with different bit rate ranges have different overhead areas, different numbers of overhead sections, and different structures. In contrast, claim 1 recites the desired result that is not limited to the steps taught in the application for achieving the results.
Remaining Claims.
Independent claim 9 recites a CRM performing the mapping functionality of claim 1. This has a scope similar to claim 1.
Independent claim 10 recites a memory and processor performing the mapping functionality of claim 1. This has a scope similar to claim 1.
The dependent claims add additional limitations but fail to address the issues raised with regard to the independent claims. As a result, the dependent claims also have a scope that would include steps that go beyond the teachings of the present application.
The Claims do not Recite the Particular Structure, Materials, or Steps.
As discussed above, the application teaches how to make and use the invention using particular structure, materials, and steps to implement the mapping of clients within different bit rate ranges to containers with different overhead areas. As also discussed above, the claims recite the desired functionality/results, but do not recite the particular structure, materials, or steps that accomplish the claimed functionality/results. This results in claims having a scope that is much broader than the teachings of the application.
When considering the teachings of the application and the scope of the claims, as discussed above, see MPEP 2173.05(g), 4th paragraph:
… Further, without reciting the particular structure, materials or steps that accomplish the function or achieve the result, all means or methods of resolving the problem may be encompassed by the claim. Ariad Pharmaceuticals., Inc. v. Eli Lilly & Co., 598 F.3d 1336, 1353, 94 USPQ2d 1161, 1173 (Fed. Cir. 2010) (en banc). Unlimited functional claim limitations that extend to all means or methods of resolving a problem may not be adequately supported by the written description or may not be commensurate in scope with the enabling disclosure, both of which are required by 35 U.S.C. 112(a) and pre-AIA 35 U.S.C. 112, first paragraph. In re Hyatt, 708 F.2d 712, 714, 218 USPQ 195, 197 (Fed. Cir. 1983); Ariad, 598 F.3d at 1340, 94 USPQ2d at 1167. …
This supports a finding that the broad scope of the claims may not be commensurate with the teachings in the disclosure.
While the claims do not need to include every detail of the embodiments disclosed in the application, the scope of the claims must be commensurate with the teachings of the application. However, in the present case, the claims recite broad functional language and desired results while the teachings have a more limited scope in which particular operations and calculations are used to achieve the desired results.
No Teaching of a General Case for the Full Scope of the Claims.
The Examiner also notes that there is no teaching of an apparatus/method with the broad scope recited in the claims. In particular, there is no teaching of a general case that can perform the claimed results/functionality without the steps taught in the application.
If such a general case were contemplated or discovered by the inventors (e.g., a way to map a client with any bit rate range to a container with any overvalue in a useful way), its disclosure and a description of its operation would be expected as part of the application in order to support broad claims, such as claim 1. This is particularly true because, as discussed above, the embodiments that are disclosed in the application require complex and particular steps/ algorithms. These steps/algorithms would be unnecessary if a general case had been known by the inventors, and yet the application does not include a disclosure of a general case. This supports a conclusion that the scope of the claims is not commensurate with the teachings of the application.
Other Considerations.
The nature of the invention is optical transmission and reception apparatuses and methods. The components used in the various embodiments were known to one of ordinary skill. For example, one or ordinary skill would be familiar with components, such as optical transmitters, optical receivers, optical waveguides, and signal processors for controlling the transmitters and receivers in the context of the invention. Therefore, no teachings of how to make these individual components is required.
The application teaches how operate an optical system (steps/functionality to map clients to containers in a particular way) to achieve the desired results. These combinations are particular and complex. Nonetheless, one or ordinary skill would know how to make and use the disclosed embodiments of the invention from the teachings of the application.
Furthermore, it would have been obvious that some elements may be modified or replaced with other elements known to have the same or similar functionality, and to make some modifications to the particular structures disclosed.
Similarly, one of ordinary skill would also know how to perform other tasks in the present technological area and related to the invention, such as providing power to components (although power supplies and power specifications are not explicitly taught in the application), and splicing/coupling the electrical and optical components together (although this is not explicitly taught in the application), and managing the temperature of electrical and optical components which are susceptible to performance degradation and undesirable operational variations based on temperature (although this is not explicitly taught in the application), and shielding components from EM interference that can be generated by such devices (although this is not explicitly taught). Although this is not an exhaustive list, the obvious modifications based on the disclosure and the knowledge of one or ordinary skill are nonetheless of a limited scope.
However, these modifications do not address the issues raised above regarding the disparity between the scope of the claims and the teachings of the application.
Experimentation.
As discussed above, the claims include many possible steps/algorithms and the application does not teach the full scope of the claims. As a result, if one of ordinary skill were to attempt to make and use the full scope of the claims, it would require making, testing, or otherwise evaluating all (or at least a very large number of) possible combination of steps/algorithms within the scope of the claims to find what works to perform the claimed functionality. This results in a practically unlimited number of embodiments that would need to be made, tested, or otherwise evaluated to determine which embodiments within the scope of the claims are operative and which are inoperative. In other words, it would require almost infinite experimentation in order to make and use the full scope of the claims.
This supports a finding that undue experimentation would be required to make and use the full scope of the claims.
Conclusion.
After careful consideration the Examiner has concluded that the specification does not enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the invention commensurate in scope with these claims. In other words, the specification fails to teach those skilled in the art how to make and use the full scope of the claimed invention without ‘undue experimentation’.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 2002/0051466 (Bruckman) teaches that data over networks is transmitted at different bit rates, and this causes problems. See:
[0004] Problems of packet delay are exacerbated particularly over low-bandwidth channels, such as copper wire access networks. This type of network is used in Digital Subscriber Line (DSL) service, which typically offers variable data rates that range from about 100 kbps up to 2.3 Mbps, depending on line quality and network conditions. To exemplify the problem, assume that packets carried over DSL lines can range in size from 64 bytes up to 1544 bytes, as is common in Internet Protocol (IP) networks. At 2 Mbps, a 64-byte packet will take only 250 .mu.s to transmit, while at 128 kbps, it will take 4 ms. On the other hand, at 128 kbps, a 1544-byte packet will take 96 ms to transmit. If a stream of short voice packets is interspersed with long e-mail packets over a 128 kbps channel, as may commonly happen, the voice packets will usually follow one another almost instantaneously, but will at times be delayed by as much as 96 ms while waiting for a long e-mail packet to pass. To deal with this large jitter, the receiver in such a system must have a deep buffer and will have a long, built-in delay of nearly 100 ms in delivering the packets to the user.
Bruckman also teaches that it was known to address this problem by separating data into smaller units (fragments) at the transmitter. These smaller units collectively form a container in which the fragments are separately transmitted and then reassemble at the receiver. See:
[0005] One solution to this problem is to fragment packets into smaller units at the transmitter, and then reassemble the packets at the receiver. For example, in Asynchronous Transfer Mode (ATM) networks, all data are transmitted in cells of exactly 53 bytes each. Each cell must carry its own five-byte header, thus adding a 10% overhead factor to the packet overhead already existing in the system. This high overhead rate must be tolerated in low-bandwidth channels, in order to keep the maximum delay of high-priority packets (such as voice) within limits of a few milliseconds. When higher bandwidth is available, however, it is desirable to use longer fragments, in order to reduce the relative transmission overhead.
This results in the total overhead size for the container (i.e., all of the fragments for a given data set) to vary depending on the number of fragments, which is a function of the bit rate. In other words, it was known to fragment packets depending on the bit rate, with the result being that the total overhead varies with bit rate. See also:
[0007] The FRF.12 agreement presents an analysis of transmission efficiency (ratio of payload to total data carried by a fragment) as a function of payload size, in which it is shown that the efficiency generally increases as the payload size grows. The agreement indicates that the maximum fragment size should be configured by the operator for each channel depending on the speed and application requirements of the channel. For variable-rate channels, such as DSL links, this means that the fragment size must be set for the worst case, i.e., the slowest possible channel speed, in order to avoid unacceptable delays. Thus, even when high-speed service becomes available, the efficiency of transmission is limited by the low-speed fragmentation constraints.
In other words, the fragment size is selected based on the speed of the channel. The invention of Bruckman also teaches to set the data length of a fragment is a function of data rate:
[0010] In preferred embodiments of the present invention, a transmitter receives datagrams for transmission over a network channel to a receiver. In the context of the present patent application and in the claims, the term "datagram" is used to refer to any block of data with a predefined destination in the network, including (but not limited to) data packets and frames. The transmitter divides the datagram into fragments, whose size is determined dynamically by the transmitter depending on network conditions and constraints. The fragment length can thus increase automatically with increasing data rate, without reprogramming by an operator, unlike variable-length fragmentation systems known in the art.
[0011] Preferably, the transmitter is preprogrammed by a user with parameters that include a maximum permissible delay in transmitting a high-priority datagram. The transmitter then determines the optimal fragment size for efficient transmission, depending on the instantaneous channel speed and the preprogrammed parameters. In contrast to the present invention, methods of fragmentation known in the art require that the fragment size be configured in advance, and do not permit dynamic size adjustment by the transmitter.
[0012] There is therefore provided, in accordance with a preferred embodiment of the present invention, a method for transmitting data over a channel having a variable transmission rate, including:
[0013] determining the rate of transmission of the data over the channel;
[0014] receiving a datagram for transmission over the channel at the determined rate of transmission;
[0015] dividing the datagram into fragments of a size no greater than a size limit that is set for the datagram responsive to the determined rate of transmission; and
[0016] transmitting the fragments over the channel.
Bruckman also teaches that a fixed overhead is used with each fragment, so that the overhead size for the entire container (e.g., all of the fragments for a particular datagram) increases as the number of fragments increases:
[0019] Further preferably, dividing the datagram into fragments includes increasing the size limit as the rate of transmission increases. Most preferably, dividing the datagram includes dividing the datagram into fragments having a fixed overhead size and a variable payload size, such that a ratio of the payload size to the overhead size increases as the rate of transmission increases. Alternatively or additionally, dividing the datagram into fragments includes setting the size limit responsive to fragmentation control parameters programmed by a human operator, wherein increasing the size limit includes increasing the limit automatically as the rate of transmission increases, substantially without alteration of the parameters.
See also FIG. 2.
US 2019/0140759 (Su) at FIG. 1 illustrates an OTN frame including overhead and payload.
PNG
media_image4.png
258
454
media_image4.png
Greyscale
FIG. 2 illustrates the structure of the OTUCn frame including overhead FA OH, OUT OH).
PNG
media_image5.png
392
404
media_image5.png
Greyscale
See also:
[0060] FIG. 2 shows a frame structure of an OTUCn frame defined for an OTUCn signal. The OTUCn frame includes n OTU subframes, and each OTU subframe includes 4 rows and 3824 columns. An Frame Alignment Overhead (FA OH) is frame positioning overhead bytes, and provides a frame synchronization and positioning function. An OTU OH is OTUCn overhead bytes. The OTUCn is managed and monitored as one signal, and a network management function of an optical channel transport unit level is provided. Most overhead information in an OTUCn overhead is carried by using an OTU OH of OTU subframe 1 (OTU subframe #1), and remaining overhead information is carried by using a plurality of other OTU subframes. The OTUCn frame is formed by adding an FA OH and an OTUCn overhead to an Optical Channel Data Unit-Cn (ODUCn) frame. The ODUCn frame includes n ODU subframes, and each ODU subframe includes 4 rows and 3824 columns. The ODUCn frame is formed by adding an ODUCn overhead to an Optical Channel Payload Unit-Cn (OPUCn) frame. The OPUCn frame includes n OPU subframes, and each OPU subframe includes 4 rows and 3810 columns. Each OPU subframe includes an overhead area of 2 columns and a payload area of 3808 columns. Each OPU subframe includes 20 5-Gbit/s tributary slots, used to carry lower-order services. Before the OTUCn frame is sent, single-byte or multi-byte interleaving processing, for example, single-byte or 16-byte interleaving processing, is performed on the n OTU subframes of the OTUCn frame based on a type of a physical interface that is to transmit the OTUCn frame, to form a serial OTUCn bit data stream. The serial OTUCn bit data stream is sent by using an optical module having a corresponding rate.
FIG. 5 illustrates a method for dividing a payload into smaller tributary slots 501, further dividing the tributary slots 502, mapping the client signal into a payload 503, adding overhead 504, and sending the signal 505..
PNG
media_image6.png
502
384
media_image6.png
Greyscale
See also:
[0068] Referring to FIG. 5, FIG. 5 is a schematic flowchart of a client signal transmission method according to an embodiment of the present invention. The method includes the following procedure.
See also FIGS. 7 and 8.
US 2022/0006550 (Su) at FIG. 3 illustrates a flowchart in which data is mapped into a plurality of frames S702 before sending S703 to the receiver S704.
PNG
media_image7.png
402
516
media_image7.png
Greyscale
See also:
[0115] S702: The transmit end maps the service data to a plurality of OTN data frames, where the OTN data frame includes an overhead area and a payload area, a length of the payload area is positively correlated with a transmission rate of the OTN data frame, and a length of the overhead area is a fixed value. The overhead area is used to carry overheads of the service data.
[0116] The overheads carried in the overhead area herein include frame header information (or referred to as framing indication information), and overhead information used for management, monitoring, and maintenance. The payload area is used to carry the service data.
In particular, the payload area varies with the transmission rate, while the overhead area is fixed.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DARREN WOLF whose telephone number is (571)270-3378. The examiner can normally be reached Monday through Friday, 7:00 AM to 3:00 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, KENNETH N. VANDERPUYE can be reached at 571-272-3078. 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.
/DARREN E WOLF/Primary Examiner, Art Unit 2634
