DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Election/Restrictions
Applicant’s election without traverse of Invention I, Claims 1 to 6 and 15 to 20, in the reply filed on 31 January 2023 is acknowledged.
Claims 7 to 14 are withdrawn from further consideration pursuant to 37 CFR 1.142(b) as being drawn to a nonelected invention, there being no allowable generic or linking claim. Election was made without traverse in the reply filed on 31 January 2023.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claim 6 is rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor, at the time the application was filed, had possession of the claimed invention.
Claim 6 sets forth a new limitation of “processing the packet for transmission with a non-routing table lookup processing flow”, which is not described by the originally-filed Specification, and represents new matter under 35 U.S.C. §112(a). Generally, there are only nine occurrences of the term ‘routing’ in the originally filed Specification, and none of these occurrences supports a limitation directed to “a non-routing table lookup processing flow”. Applicant states in the Remarks that the claim amendments are supported by ¶[0026] - ¶[0029] of the Specification, but there is no written description in these paragraphs of any “non-routing table lookup”.
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 to 6 and 15 to 19 are rejected under 35 U.S.C. 103 as being unpatentable over Lakaniemi et al. (U.S. Patent Publication 2002/0163908) in view of May et al. (U.S. Patent Publication 2006/0036434).
Concerning independent claims 1 and 15, Lakaniemi et al. discloses a method and coding algorithm for synchronizing codec modes for adaptive multi-rate (AMR) codecs in a communication session (Abstract), comprising:
“receiving, on a receiving network interface, a message during establishment of a flow given an Active Codec Set (ACS) and a codec type” – a method communicates indicia associated with an active codec-mode set pursuant to which codecs of the communications stations are operable (¶[0001]); proposed codec mode standards in a third-generation GERAN (GSM/EDGE radio access network) provide for AMR (adaptive multi-rate) functionality (¶[0004]); modes in active use at a particular time form a set of modes (“a codec type”), referenced to as an active codec-mode set (ACS) (“given an Active Codec Set (ACS)”); an AMR (adaptive multi-rate) full rate channel and an AMR half rate channel are defined; when a channel type is a half rate type, an active codec set can contain only modes which exhibit rates beneath 8 bits/s (¶[0005]); indicia associated with an active codec-mode are communicated pursuant to which codecs of communication stations are operable; RTP (real-time protocol) messages are utilized to inform a receiving station of an active codec-mode set (ACS) (“receiving . . . a message”) pursuant to which the codec of another sending station is operable; an extension to an existing real-time control protocol is used to provide an RTP message containing indicia associated with the active codec-mode set (¶[0014] - ¶[0015]); a codec-mode message generator is coupled in a codec-mode detector to receive indications of the codec mode detected (¶[0019]); SGSN (Serving GPRS Service Node) 22 and BSS/GERAN (Base Station System and GSM/EDGE Radio Access Network) 18 are interfaced by an Iu interface to provide a communication path between mobile station 12 and correspondent node 14 (“receiving, on a receiving network interface”) (¶[0026] - ¶0028]: Figure 1);
“extracting an FT value from a received packet in a received Adaptive Multi-Rate (AMR) header” – a special, or new, frame type (FT) field value (“an FT value”) is defined in a header portion of an RTP message; a value contained in the frame type portion of the RTP header is of a value indicating that the frame includes indicia associated with the active codec-mode set; a separate RTP packet (“a received packet”) is sent to provide the active codec-mode set information (¶[0016]); a codec-mode message generator is coupled in a codec-mode detector to receive indications of the codec mode detected (¶[0019]); RTP/UDP/IP headers 72 are followed by a voice frame 74, and are removed at a radio access network portion (¶[0040]: Figure 2); an adaptive multi-rate packet format includes a header portion of a codec mode request (CMR) field 84, a frame (RF) field 86, a frame type (FT) indicator field 88, and a payload quality (Q) bit field indicator 92; a frame type field value is inserted in field 88 in an RTP header portion to indicate that the particular frame contains information about the permitted codec modes; a specific value, e.g., thirteen, is inserted into the frame type field 88 that indicates that the payload portion 94 of the packet contains information about the permitted codec modes (¶[0046] - ¶[0047]: Figure 4); a frame type indicia value (“an FT value”), then, is received and removed (“extracted”) from a header portion of an RTP packet (“a received packet”) to determine an active codec-mode set in AMR;
“[once the AMR payload length is known,] processing a packet for transmission on the receiving network interface using the AMR payload length” – communicating indicia associated with an active codec-mode set facilitates communications between communication stations pursuant to a communication session (¶[0001]); standards relating to AMR support eight speech coding modes in which the modes exhibit bit rates between 4.75 and 12.2 bps (¶[0005]); specifications pertaining to another multi-mode codec are set forth that includes nine speech coding modes operable upon 16 kHz sampled signals (¶[0007]); a manner is required by which to communicate the codec codes of the active codec-mode set so that the codecs of a sending and a receiving station pair can be operable to code and decode data during a communication session (¶[0011]); radio access network 18 portion generates headers for the packets generated at the mobile station and sent in the uplink direction to the correspondent node (“processing a packet for transmission on the receiving network interface”) (¶[0039]); a voice frame 74 originating at the mobile station, is routed from the radio link to the radio access network portion; once the voice frame is received at the radio access network portion, the RTP/UDP/IP header information is added to the voice frame to permit routing through the network to the corresponding node (“processing a packet for transmission on the receiving network interface”) (¶[0041]: Figure 4); alternatively, “processing a packet for transmission on the receiving network interface” can be broadly construed as decoding speech samples at a receiving station according to a speech coding mode after the coded speech samples and indicia of the coding mode are received and a codec mode is established for the session.
Concerning independent claims 1 and 15, Lakaniemi et al. does not expressly disclose the limitations of “preparing a map where each bit of the map indicates a Frame Type (FT) of the flow given during establishment of the flow”, “using the extracted FT value, checking if a rate corresponding to the extracted FT is supported and if supported, obtaining an AMR payload length for that rate from a table”, and processing “once the AMR payload length is known”. Still, it appears implicit that there is pre-existing “map” that indicates a Frame Type as illustrated in Figure 4 of Lakaniemi et al. That is, Lakaniemi et al. discloses, at ¶[0046] - ¶[0047]: Figure 4, that there is frame type (FT) indicator field 88 of bits 5 to 8 of a packet format. Here, a “map” may refer to some specific value of bits 5 to 8 that corresponds to a set of permitted codec modes, e.g., a value of 13 in bits 5 to 8 is ‘mapped’ to a set of codec modes in an active codec-mode set (ACS). This pre-defined map, then, is at least provided “during establishment of a flow”. Moreover, Lakaniemi et al., at ¶[0046] - ¶[0047]: Figure 4, discloses that a packet format includes a payload portion 94 of 148 bits and padding bits 96. This payload portion of 148 bits is “a payload length”. Implicitly, stations and terminals can have different capabilities, so that a codec mode might be or might not be supported, and this is determined during establishment of a session to ensure that the two stations or terminals are synchronized with the same coding/decoding mode.
Concerning independent claims 1 and 15, May et al. teaches the limitations of “preparing a map where each bit of the map indicates a Frame Type (FT) of the flow during establishment of the flow”, “using the extracted FT value, checking if the rate is supported and if supported, obtaining a payload length for that rate from a table”, and processing “once the AMR payload length is known”. Generally, May et al. teaches communication systems for decoding variable bit rate signals which are transmitted using one of a plurality of different coding rates. (¶[0001]) Frame type indicators reflect a transmitter’s currently employed speech coding, and a frame type indicator may be transmitted to the receiver e.g., a base or mobile station’s receiver, so that it can employ the appropriate speech decoding techniques. Typically, a frame type indicator may include just a few bits which are conveyed along with the data fields. (¶[0011]) A frame type indicator is associated with at least two different coding rates, and the frame type indicator is selected from at least two frame type indicators depending upon the selected one of the at least two different coding rates, wherein the at least two frame type indicators have a different bit length. (¶[0015]) Specifically, Figure 3 illustrates a relationship between payload data Nr, supplementary data Dr, and unused bits Ur, which provide for a fixed frame size of 320 bits. The coding rates r specified therein are relative to a maximum output bit rate. These bits are mapped into each frame in any desired manner for each coding rate as illustrated in Figure 4. A frame type indicator can be transmitted in each frame to inform the receiver’s decoder to switch to an appropriate mode to properly decode each frame. A different frame type pattern is inserted into each frame for ½, ¼, and 1/8 frame rates, and a receiver can perform a pattern matching process to determine the rate of a received frame. (¶[0033] - ¶[0037]: Figure 3) Here, Figure 3 illustrates a “map” and “a table” that associates a codec mode derived from a frame type indicator and Nr which is a “payload length”. That is, a frame type pattern “maps” to a codec rate, e.g., full rate f or half-rate f/2, and “a payload length” of 278 bits is determined for full rate f or “a payload length” of 136 bits is determined for a half-rate f/2 from a “table” of Figure 3. An objective is to provide a frame format for decoding variable rate signals that are encoded using one of a plurality of coding rates. (Abstract; ¶[0001]) It would have been obvious to one having ordinary skill in the art to provide a map between a frame type and a codec mode and to obtain a payload length from a table as taught by May et al. to synchronize operation of adaptive multi-rate codec modes in Lakaniemi et al. for a purpose of determining a frame format for decoding variable rate signals.
Concerning claims 2 and 16, Lakaniemi et al. discloses an AMR (adaptive multi-rate) full rate channel and an AMR half rate channel are defined; when a channel type is a half rate type, an active codec set can contain only modes which exhibit rates beneath 8 bits/s (¶[0005]); a change in channel-type between a half-rate to a full-rate channel, and vice versa, might necessitate a change of the active codec-mode set (¶[0009]). Similarly, May et al. teaches that a different frame type pattern is inserted into each frame for ½, ¼, and 1/8 frame rates, and a receiver can perform a pattern matching process to determine the rate of a received frame. (¶[0033] - ¶[0037]: Figure 3)
Concerning claims 3 and 17, Lakaniemi et al. discloses that a special, or new, frame type (FT) field value is defined in a header portion of an RTP message; a value contained in the frame type portion of the RTP header is of a value indicating that the frame includes indicia associated with the active codec-mode set; a separate RTP packet is sent to provide the active codec-mode set information (¶[0016]); a frame type field value is inserted in field 88 in an RTP header portion to indicate that the particular frame contains information about the permitted codec modes; a specific value, e.g., thirteen, is inserted into the frame type field that indicates that the payload portion 94 of the packet contains information about the permitted codec modes (¶[0046] - ¶[0047]: Figure 4). Here, a frame type field value is associated with an active codec-mode set of coding rates that “maps” a frame type field value to a set of coding rates (“wherein preparing the map comprises preparing a rate to frametype map”). Similarly, May et al. teaches that a different frame type pattern is inserted into each frame for rates ½, ¼, and 1/8 frame rates, and a receiver can perform a pattern matching process to determine the rate of a received frame. (¶[0033] - ¶[0037]: Figure 3) Specifically, Figures 5 and 6 illustrate strategies for mapping a frame type indicator to a coding rate (“wherein preparing the map comprises preparing a rate to frametype map”). Figure 5 provides a fixed number of bits of a frame type indicator that ‘maps’ to coding rates of r=1 (full rate), r=1/2 (half rate), r=1/4, and r=1/8, and Figure 6 provides a different frame type pattern including unused bits Ur that ‘maps’ to coding rates of r=1 (full rate), r=1/2 (half rate), r=1/4, and r=1/8.
Concerning claims 4 to 5 and 18 to 19, May et al. teaches “obtaining the AMR payload length for that rate from the table comprises obtaining the AMR payload length for that rate from a rate to frame type payload length table” as illustrated in Figure 3, where “a payload length” of 278 bits is determined for full rate f or “a payload length” of 136 bits is determined for a half-rate f/2 from a “table”, which is “a static table”. That is, a frame type “maps” to a rate, and a rate determines a payload length in Figure 3. (¶[0033] - ¶[0037]: Figure 3) Here, May et al. teaches “different payload lengths for at least two different rates” because a payload length is 278 bits for a full rate and 136 bits for a half-rate. (¶[0035]: Figure 3)
Concerning claim 6, May et al. teaches “processing the packet for transmission with a non-routing table lookup processing flow” because a determination of a frame length Nr from a table of Figure 3 does not include any ‘routing’. (¶[0033]: Figure 3) That is, to the extent that of scope of the limitation “a non-routing table lookup processing flow” is clear from the originally-filed Specification, this may be broadly construed as a simple table lookup operation that does not perform routing in May et al. Looking up a value in a table of a frame length for a codec mode does not ordinarily involve any ‘routing’ (“a non-routing table lookup”).
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Lakaniemi et al. (U.S. Patent Publication 2002/0163908) in view of May et al. (U.S. Patent Publication 2006/0036434) as applied to claims 15 and 18 above, and further in view of Karimli et al. (U.S. Patent Publication 2016/0119384).
Lakaniemi et al. does not expressly disclose “wherein performing further processing comprises checking if the rate is supported”, but this appears to be implicit in any rate negotiation between base stations or terminals that support multiple modes of communication. However, Karimli et al. teaches dynamic rate adaptation during real-time communications, where a session is established over a connection with a codec rate, and a monitor component subsequently receives data indicating performance of the communication session, and performs a renegotiation of the codec rate based on the performance of the communication session. (Abstract) Two user equipment (UE) endpoints exchange capabilities in a negotiation, where UEs exchange information regarding their codecs and rates they support including AMR-WB codec rates. The UE devices exchange their bit rate modes and select the highest bit rate supported by both. (¶[0001]) A lower bit rate is more robust, and a higher bit rate provides better audio quality. (¶[0010]) During communication establishment, first UE 102 provides the IMS core 120 and the second UE 108 (called phone) with a list of capabilities. The capabilities include one or more codecs and rates, such as AMR-WB bit rate modes, AMR-NB (narrow band) codec and bit rate modes and EVS (Enhanced voice service) codec and bit rate modes, all or some of which may be supported by the first UE 102.
In one example, the first UE 102 and the second UE 108 establish the real-time LTE communication session using the highest bit rate mode that both support. (¶[0022] - ¶[0023]: Figure 1) Karimli et al., then, performs “further processing” to determine if a rate is supported at a highest rate based on network conditions in a session renegotiation. An objective is to request a change in communication session codec rate in response to utilization or congestion levels. (¶[0014]) It would have been obvious to one having ordinary skill in the art to perform further processing to check if a codec rate is supported between first and second user equipment as taught by Karimli et al. in a synchronization of operation of codecs in a communication session of Lakaniemi et al. for a purpose requesting a change in a communication session codec rate in response to utilization levels or congestion levels.
Response to Arguments
Applicant’s arguments filed 05 January 2026 have been fully considered but they are not persuasive.
Applicant provides some minor amendments to independent claims 1 and 15 to render the limitations of the two independent claims consistent and to overcome a claim objection. Mainly, Applicant presents arguments traversing the prior rejection of these independent claims being obvious under 35 U.S.C. §103 over Lakaniemi et al. (U.S. Patent Publication 2002/0163908) in view of May et al. (U.S. Patent Publication 2006/0036434). Firstly, Applicant argues that May et al. does not appear to teach a map and a table as two distinct elements, and argue that it is improper for a rejection to rely on the same structure in the prior art to satisfy two different elements of the claims. Secondly, Applicant argues that May et al. does not appear to teach preparing content during establishment of a flow in the limitation of “preparing a map where each bit of the map indicates a Frame Type (FT) of the flow given during establishment of the flow”. Thirdly, Applicant argues that May et al., at ¶[0047], states that “a specific frame type value is inserted into the header portion to indicate that the particular frame contains information about the allowed codec instead of the frame being a conventional AMR frame”, but the claim language requires extracting an FT value from a received packet “in a received Adaptive Multi-Rate (AMR) header.” (Here, Applicant appears to have erroneously cited ¶[0047] of May et al., but this is actually stated at ¶[0047] of Lakaniemi et al.) Applicant concludes that Lakaniemi et al. and May et al. do not disclose or teach “extracting an FT value from a received packet in a received Adaptive Multi-Rate (AMR) header” as set forth by the independent claims.
Applicant’s amendments to dependent claim 6 raise issues of new matter under 35 U.S.C. §112(a) for the limitation of “a non-routing table lookup processing flow”. Applicant’s Specification, as originally filed, does not provide support for this limitation. The examiner suggests that this limitation be canceled due to this lack of support and because a scope of the limitation of “a non-routing table lookup processing flow” is not clearly described in the Specification.
Generally, Applicant’s arguments are not persuasive to overcome the prior rejection of the independent claims as being obvious under 35 U.S.C. §103 over Lakaniemi et al. (U.S. Patent Publication 2002/0163908) in view of May et al. (U.S. Patent Publication 2006/0036434). This rejection is being maintained. One dependent claim continues to be rejected as obvious further in view of Karimli et al. (U.S. Patent Publication 2016/0119384).
Firstly, Applicant’s argument that it is improper for a rejection to rely on the same structure in a reference to satisfy two different elements is not persuasive. Here, there appears to be no principle of patent case law that supports this position as argued by Applicant. The examiner contends that this would be evaluated on a case-by-case basis and depends upon the facts of what is disclosed by the references, but that it is entirely conceivable that one structure in a prior art reference could perform the functionality of two limitations. Still, Lakaniemi et al. could be construed to disclose “a mapping” in Figure 4, and May et al. could be construed to teach “a table” in Figure 3. That is, “a map” can be construed as a function that takes a bit pattern, e.g., ‘13’, of a frame type specified in a header of a frame and translates that frame type into a frame type value, e.g., half-rate AMR. Lakaniemi et al. discloses a frame type indicator field 88, which is simply a string of bits, and this string of bits is ‘mapped’ by a function to a specific AMR codec type or “frame type (FT) value”, e.g., half-rate or full-rate. This ‘mapping’ of a string of bits representing a frame type to a determination of specific codec does not determine the frame length, but only the frame type, e.g., a specific frame type value of 13 ‘maps’ to a half-rate codec in AMR. Then May et al. provides a table in Figure 3 that determines “an AMR payload length”. This payload length is designated as payload data Nr with a payload length of 278 for full length f, a payload length of 136 for half rate f/2, a payload length of 57 for quarter rate f/4, etc. Consequently, Applicant’s argument is not persuasive because there is no principle of patent law that supports their argument, and because the prior art does not require that “a map” and “a table” are the same thing in the prior art.
Secondly, Applicant’s argument is not persuasive that preparing a map is not performed “during establishment of a flow” by May et al. Here, “preparing a map . . . during establishment of the flow” can be construed as performing a mapping of a given frame type indicator field 88 to a frame type to a codec type in Lakaniemi et al. That is, ‘a mapping’ is a determination of a frame type that occurs during a given communication even if the nature of a function constituting the map is fixed. When a codec type is ‘mapped’ from a frame type indicator as a frame is received, this ‘mapping’ is determined “during establishment of the flow’. Similarly, May et al. provides “a table” in Figure 3 that is applied to an ongoing communication to establish a frame length Nr for a given frame type “during establishment of the flow”. Notably, Applicant’s claims 6 and 19 set forth a limitation that a table is “a static table” so that a correspondence between a frame type and a frame length is fixed for all communications. May et al., at ¶[0032], describes Figures 3 and 4 as characteristic of a standard for tandem-free operation in IS-733, and Applicant’s invention appears to do nothing more than is set forth by this standard.
Thirdly, Applicant’s argument is not persuasive that ¶[0047] of May et al. does not teach “extracting an FT value from a received packet in a received Adaptive Multi-Rate (AMR) header”. Here, Applicant’s argument is simply citing an alternative embodiment out of context of what is disclosed by Lakaniemi et al., and Applicant mistakenly cites ¶[0047] as being in May et al., when it is actually ¶[0047] of Lakaniemi et al. However, looking at the entire context of ¶[0046] - ¶[0047] of Lakaniemi et al., it is evident that an adaptive multi-rate packet format is the main embodiment intended, even if provision could be made in some embodiments of a codec mode instead of, e.g., in addition to, ‘a conventional AMR frame’. That is, just looking at the abstract of the patent publication, AMR codec modes are the main focus of Lakaniemi et al. Granted, Lakaniemi et al., at ¶[0047], describes one alternate embodiment that a codec can be determined for something else besides a conventional AMR frame, but the main embodiments are directed to AMR frames. See Lakaniemi et al., Abstract and ¶[0046] - ¶[0047]:
Apparatus, and an associated method, for facilitating synchronization of the operational codec modes of communication stations which communicate pursuant to a communication session. Signaling is provided to indicate allowed AMR (adaptive multi rate) codec modes to optimize speech connections in a GSM/EDGE radio access network (GERAN).
[0046] FIG. 4 illustrates an adaptive multi-rate packet format, shown generally at 82. The packet format includes a header portion, here shown to include a codec mode request (CMR) field 84, a frame (RF) field 86, a frame type (FT) indicator field 88, and a payload quality (Q) bit field indicator 92. A payload portion 94 of, here, 148 bits and padding bits 96 form the remainder of the AMR packet.
[0047] In another embodiment of the present invention, a specific frame type field value is inserted in the field 88 in the RTP header portion to indicate that the particular frame contains information about the allowed codec modes instead of the frame being a conventional AMR frame.
(emphasis added)
One skilled in the art could understand there might be two ways of determining a payload length: (1) a payload length could be specified in one of the fields of an encoded frame, and the coding mode and the payload length could be determined just from the bit information in the frame, or (2) only a coding mode could be specified in the fields of an encoded frame, and the payload length could be determined from a table that maps the coding mode to a payload length. Here, Applicant’s invention appears to correspond to (2), and Figure 3 of May et al. provides “a table” that maps a coding mode as specified in an encoded frame to payload length Nr of a coding mode.
Applicant’s arguments, then, are not persuasive. New grounds of rejection under 35 U.S.C. §112(a) are necessitated by amendment. All of the new grounds of rejection are necessitated by amendment. Accordingly, this rejection is properly FINAL.
Conclusion
The prior art made of record and not relied upon is considered pertinent to Applicant's disclosure.
Gao et al. discloses related prior art.
Andonegui et al. (WO) includes Figure 3 that is similar to Figure 3 of May et al.
Applicant's amendment necessitated the new grounds 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 MARTIN LERNER whose telephone number is (571) 272-7608. The examiner can normally be reached Monday-Thursday 8:30 AM-6:00 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Richemond Dorvil can be reached on (571) 272-7602. 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.
/MARTIN LERNER/Primary Examiner
Art Unit 2658 March 17, 2026