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 .
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hao et al. (US 20240267324 A1) in view of Thubert et al. (US 20200259680 A1).
Regarding claim 1, Hao teaches a method implemented within a backend network of a web scale network, ([0079; 0085] network system backplane, where the system includes hosting web based services.) the method comprising: (0006; packet forwarding method)
registering,(recording information about the output interface device equivalent to registering) with a service control plane,(control plane) a plurality of egress endpoints (output interface device) and status of the egress endpoints (status of the outbound (egress) interface devices;) (0080; The control plane advertises and learns of a route, generates a forwarding table, processes signaling and a protocol packet, configures and maintains a device status, and the like; 0032; receiving a second notification message from the second forwarding chip, where the second notification message indicates a congested state of the second outbound interface of the second forwarding chip; and recording the congested state of the second outbound interface based on the second notification message.)
distributing, by the service control plane to a plurality of ingress virtual output queues (VOQs) (the control plane generates and provides forwarding tables to the forwarding plane), registration information relating to the plurality of egress endpoints;(the control plane generates and provides forwarding tables to the forwarding plane) (0080; The forwarding plane includes each forwarding chip. For example, the forwarding chip 231 and the forwarding chip 232 are disposed on the line card 230, and a switching chip is disposed on the switching board 220. The control plane advertises and learns of a route, generates a forwarding table, processes signaling and a protocol packet, configures and maintains a device status, and the like. The control plane delivers the generated forwarding table to the forwarding plane. The forwarding chip 232 on the forwarding plane searches a table for and forwards, based on the forwarding table delivered by the control plane, a packet received by the network interface (not shown in the figure). The forwarding table delivered by the control plane is stored, for example, in a memory (not shown in the figure) on the line card. In some embodiments, the control plane and the forwarding plane may be deployed on different physical devices.)
based at least in part on the distributing, (forwarding table see mapping above) scheduling packets for transmission (scheduling flow from VOQ to engress) from the plurality of ingress VOQs to the plurality of egress endpoints; (0249; The VOQ buffers ingress traffic before the ingress traffic enters the switching board, to avoid head-of-line (HOL) blocking. In a direction to an egress, a scheduler schedules a service flow corresponding to an ingress VOQ, and sends permitted credit values (credits) of different bandwidths to all service flows flowing to the egress, to accurately allocate a bandwidth based on a user service level agreement (SLA) and ensure quality of service (QOS).)
and forwarding, by the plurality of ingress VOQs to the plurality of egress endpoints, packets (forwarding packets from the ingress VOQ to the egress). ([0164] The target outbound interface is an outbound interface used to forward the first data packet in the M outbound interfaces. There are a plurality of implementations of selecting the target outbound interface. [0074] The line card 230 is also referred to as an interface board (interface board), a line processing unit (LPU), or a service board. The line card 230 is configured to: provide various service interfaces and forward a packet; 0077; When forwarding chips on different line cards need to interact, the switching board 220 is configured to forward data between forwarding chips on different line cards, to implement mutual communication between the forwarding chips. [0084] The packet forwarding method provided in embodiments of this application is applied to a network that includes a plurality of chassis-shaped devices and a plurality of hosts. The plurality of chassis-shaped devices are connected to each other. For a specific connection manner between the plurality of chassis-shaped devices, refer to the architecture shown in FIG. 1, FIG. 2, or FIG. 3. Optionally, each chassis-shaped device has a hardware structure shown in FIG. 4 or FIG. 5. The plurality of chassis-shaped devices are configured to forward a data packet from a source host to a destination host, to support data exchange between different hosts. [0098] The method shown in FIG. 7 is described by using, as an example, a scenario in which a first host is connected to the first chassis-shaped device and the second host is connected to the second chassis-shaped device. In the process of forwarding the data packet, the first chassis-shaped device is responsible for receiving the data packet from the first host, and forwarding the data packet to the second chassis-shaped device. The second chassis-shaped device is responsible for forwarding, to the second host, a data packet whose destination is the second host. [0249] The uplink chip maintains a VOQ for each outbound interface. If an outbound interface of an inter-chassis interconnection link is congested, the switching chip back presses a congested state to the uplink chip. Consequently, packets in the VOQ queue are backlogged. The VOQ is an independent queue maintained by the chassis-shaped device for different outbound interfaces. The VOQ buffers ingress traffic before the ingress traffic enters the switching board, to avoid head-of-line (HOL) blocking. In a direction to an egress, a scheduler schedules a service flow corresponding to an ingress VOQ, and sends permitted credit values (credits) of different bandwidths to all service flows flowing to the egress, to accurately allocate a bandwidth based on a user service level agreement (SLA) and ensure quality of service (QOS). [0250] During route forwarding, the uplink chip determines a queue depth of the VOQ corresponding to the outbound interface. If the queue depth of the VOQ exceeds a configured threshold, the uplink chip determines that the outbound interface corresponding to the VOQ is congested. If there are a plurality of outbound interfaces of a shortest path, the uplink chip selects the remaining outbound interfaces of the shortest path for forwarding. If all outbound interfaces of the shortest path are congested, the uplink chip selects an outbound interface of a non-shortest path for forwarding.)
Hao does not explicitly teach the underlined a method implemented within a Clos configured backend network of a web scale network,
In an analogous art Thubert teaches a method ([0024] method) implemented within a Clos configured backend network (0079; a 2-planes canonical Clos is put together for the backbone and access layers) of a web scale network ([0077] Hence, the propagation of the multicast message throughout the redundant multicast trees 104 enables any network device in the fat tree network topology 100 to operate in operation 78 as a VxLAN ingress endpoint for traffic “(*,G”) destined for an overlay fabric VxLAN egress endpoint: the ingress endpoint can be selected by the management device 14 and/or auto-selected by the VxLAN egress endpoint, as appropriate. [0078] As apparent from the foregoing, the example embodiments enable deployment of multiple redundant multicast trees in a fat tree topology, also referred to as a “CLOS” topology, for reliable delivery of multicast traffic. [0079] FIG. 7 illustrates the management device 14 applying multiple multicast trees to a secondary smart grid substation. In that case, a degenerate variation is proposed whereby a 2-planes canonical Clos is put together for the backbone and access layers, while the IEDs form a third layer. That third layer acts as leaves in this example. The planes are illustrated below as a blue (dark) and a red (shaded) plane, and the planes only meet at the level of the IEDs, since they are suited for end-to-end redundancy protocols such as PRP and HSR. Hence, FIG. 7 illustrates the management device computing the trees in different planes, which makes the trees non congruent by definition.)
It would have been obvious to one of ordinary skill in the art prior to the effective filing of the application to modify the teachings of [Hao] to include [a Clos topology] as is taught by [Thubert].
The suggestion/motivation for doing so is to improve data packet distribution [0002-0007].
Regarding claim 2, Hao in view of Thubert teach the method of claim 1, and is disclosed above, Hao further teaches wherein the service control plane comprises a distributed service control plane. (0193; Fig 7-9 showing control plane procedure between multiple devices and is therefore equivalent to distributed service control plane)
Regarding claim 3, Hao in view of Thubert teach the method of claim 1, and is disclosed above, Hao further teaches further comprising:
updating the registration information relating to the plurality of egress endpoints to provide updated registration information, (The specification defines the updated registration information as being congestion information [0026]; Hao teaches [0130] In some embodiments, the first chassis-shaped device determines the congested state of the outbound interface based on at least one of a queue depth, bandwidth utilization, a buffer (buffer) length, and a remaining bandwidth of the outbound interface. [0032] and recording the congested state of the second outbound interface based on the second notification message. [0036] In a possible implementation, the second notification message includes an identifier of the second forwarding chip, an identifier of the second outbound interface, and a congested state identifier. [0040] In the implementation, the switching chip back presses the congested state of the outbound interface, so that processing overheads caused when a forwarding chip on which the outbound interface is located notifies another forwarding chip of the congested state are reduced when the forwarding chip can be aware of the congested state of the interconnection link. [0228] For a forwarding chip i in the N forwarding chips, the forwarding chip i monitors whether each outbound interface of the forwarding chip i is faulty. If an outbound interface a of the forwarding chip i is faulty, the forwarding chip i generates a fault notification message, and sends the fault notification message to (N−1) other forwarding chips different from the forwarding chip i in the N forwarding chips. Each of the (N−1) other forwarding chips receives the fault notification message of the forwarding chip i, determines, based on the fault notification message, that the outbound interface a is faulty, and records a faulty state of the outbound interface a. The other forwarding chips query an ECMP group that includes the outbound interface a in a forwarding entry, and delete the outbound interface a from the ECMP group that include the outbound interface a. [0131] For example, the congested state is determined based on the queue depth. For example, the first chassis-shaped device obtains a queue depth of each of the M outbound interfaces. The first chassis-shaped device compares the queue depth of each outbound interface with a depth threshold. If a queue depth of an outbound interface exceeds the depth threshold, the first chassis-shaped device determines that the outbound interface is in a congested state. If a queue depth of an outbound interface is less than or equal to the depth threshold, the first chassis-shaped device determines that the outbound interface is in a non-congested state. Optionally, the congested state further includes a moderately congested state and a heavily congested state. Different depth thresholds are used to determine whether the congested state is a moderately congested state or a heavily congested state. For example, the depth threshold includes a first depth threshold and a second depth threshold, and the first depth threshold is greater than the second depth threshold. If a queue depth of an outbound interface exceeds the first depth threshold, the first chassis-shaped device determines that the outbound interface is in a heavily congested state. If a queue depth of an outbound interface does not exceed the first depth threshold but exceeds the second depth threshold, the first chassis-shaped device determines that the outbound interface is in a moderately congested state.)
wherein the updated registration information comprises congestion information related to the plurality of egress endpoints; (Mapping above + [0139] For a forwarding chip i in the N forwarding chips, the forwarding chip i determines a congested state of each outbound interface of the chip, and the forwarding chip i generates a congestion notification message based on the congested state of each outbound interface, and sends the congestion notification message to (N−1) other forwarding chips different from the forwarding chip i in the N forwarding chips. Each of the (N−1) other forwarding chips receives the congestion notification message of the forwarding chip i, and records the congested state of each outbound interface of the forwarding chip i based on the congestion notification message of the forwarding chip I; [0033] In the implementation, an intra-chassis inter-chip congestion awareness and notification mechanism is implemented, so that a current congested state of an interconnection link between a local chassis and another chassis can be aware of in a timely manner, and a forwarding path with better comprehensive performance is selected based on the congested state during packet forwarding.)
distributing, by the service control plane to a plurality of ingress VOQs, the updated registration information relating to the plurality of egress endpoints; (The control plane generates the forwarding table, and records updated congested states, and then delivers and provides the forwarding table mapping above + 0080; The control plane delivers the generated forwarding table to the forwarding plane. The forwarding chip 232 on the forwarding plane searches a table for and forwards, based on the forwarding table delivered by the control plane, a packet received by the network interface (not shown in the figure). The forwarding table delivered by the control plane is stored, for example, in a memory (not shown in the figure) on the line card. In some embodiments, the control plane and the forwarding plane may be deployed on different physical devices. [0255] The forwarding chip 2 monitors a congested state of the interface 10 and a congested state of the interface 11. When the interface 10 of the forwarding chip 2 is congested, the forwarding chip 2 generates a notification message, and sends the notification message to a forwarding chip 1. The notification message includes a TB ID of the forwarding chip 2, a TP ID of the interface 10, and a congestion degree. After receiving the notification message sent by the forwarding chip 2, the forwarding chip 1 records a congested state of the interface 10 in a forwarding table.
based at least in part on distributing the updated registration information (congestion data see mapping above), further scheduling packets (Ingress VOQ flow scheduler scheduling flow to the egress) for transmission from the plurality of ingress VOQs (VOQs ingress traffic)to the plurality of egress endpoints (flowing to the egress); ([0249] The uplink chip maintains a VOQ for each outbound interface. If an outbound interface of an inter-chassis interconnection link is congested, the switching chip back presses a congested state to the uplink chip. Consequently, packets in the VOQ queue are backlogged. The VOQ is an independent queue maintained by the chassis-shaped device for different outbound interfaces. The VOQ buffers ingress traffic before the ingress traffic enters the switching board, to avoid head-of-line (HOL) blocking. In a direction to an egress, a scheduler schedules a service flow corresponding to an ingress VOQ, and sends permitted credit values (credits) of different bandwidths to all service flows flowing to the egress, to accurately allocate a bandwidth based on a user service level agreement (SLA) and ensure quality of service (QOS). [0250] During route forwarding, the uplink chip determines a queue depth of the VOQ corresponding to the outbound interface. If the queue depth of the VOQ exceeds a configured threshold, the uplink chip determines that the outbound interface corresponding to the VOQ is congested. If there are a plurality of outbound interfaces of a shortest path, the uplink chip selects the remaining outbound interfaces of the shortest path for forwarding. If all outbound interfaces of the shortest path are congested, the uplink chip selects an outbound interface of a non-shortest path for forwarding.)
and based at least in part on the further scheduling, (flow scheduler) forwarding, by the plurality of ingress VOQs to the plurality of egress endpoints, packets. ([0249] The uplink chip maintains a VOQ for each outbound interface. If an outbound interface of an inter-chassis interconnection link is congested, the switching chip back presses a congested state to the uplink chip. Consequently, packets in the VOQ queue are backlogged. The VOQ is an independent queue maintained by the chassis-shaped device for different outbound interfaces. The VOQ buffers ingress traffic before the ingress traffic enters the switching board, to avoid head-of-line (HOL) blocking. In a direction to an egress, a scheduler schedules a service flow corresponding to an ingress VOQ, and sends permitted credit values (credits) of different bandwidths to all service flows flowing to the egress, to accurately allocate a bandwidth based on a user service level agreement (SLA) and ensure quality of service (QOS). [0250] During route forwarding, the uplink chip determines a queue depth of the VOQ corresponding to the outbound interface. If the queue depth of the VOQ exceeds a configured threshold, the uplink chip determines that the outbound interface corresponding to the VOQ is congested. If there are a plurality of outbound interfaces of a shortest path, the uplink chip selects the remaining outbound interfaces of the shortest path for forwarding. If all outbound interfaces of the shortest path are congested, the uplink chip selects an outbound interface of a non-shortest path for forwarding.)
Regarding claim 4, Hao in view of Thubert teach the method of claim 3, and is disclosed above, Hao further teaches wherein distributing the updated registration information comprises publishing, (delivering by the control the forwarding table including recorded congested state information) by the service control plane, (0080; The control plane advertises and learns of a route, generates a forwarding table, processes signaling and a protocol packet, configures and maintains a device status, and the like. The control plane delivers the generated forwarding table to the forwarding plane. The forwarding chip 232 on the forwarding plane searches a table for and forwards, based on the forwarding table delivered by the control plane, a packet received by the network interface (not shown in the figure). The forwarding table delivered by the control plane is stored, for example, in a memory (not shown in the figure) on the line card. In some embodiments, the control plane and the forwarding plane may be deployed on different physical devices. (0032; receiving a second notification message from the second forwarding chip, where the second notification message indicates a congested state of the second outbound interface of the second forwarding chip; and recording the congested state of the second outbound interface based on the second notification message.) [0255] The forwarding chip 2 monitors a congested state of the interface 10 and a congested state of the interface 11. When the interface 10 of the forwarding chip 2 is congested, the forwarding chip 2 generates a notification message, and sends the notification message to a forwarding chip 1. The notification message includes a TB ID of the forwarding chip 2, a TP ID of the interface 10, and a congestion degree. After receiving the notification message sent by the forwarding chip 2, the forwarding chip 1 records a congested state of the interface 10 in a forwarding table.))
one or more messages related to the updated registration information (0032; receiving a second notification message from the second forwarding chip, where the second notification message indicates a congested state of the second outbound interface of the second forwarding chip; and recording the congested state of the second outbound interface based on the second notification message.) [0255] The forwarding chip 2 monitors a congested state of the interface 10 and a congested state of the interface 11. When the interface 10 of the forwarding chip 2 is congested, the forwarding chip 2 generates a notification message, and sends the notification message to a forwarding chip 1. The notification message includes a TB ID of the forwarding chip 2, a TP ID of the interface 10, and a congestion degree. After receiving the notification message sent by the forwarding chip 2, the forwarding chip 1 records a congested state of the interface 10 in a forwarding table.)
to subscriber ingress VOQs of the plurality of ingress VOQs. (0080; The control plane advertises and learns of a route, generates a forwarding table, processes signaling and a protocol packet, configures and maintains a device status, and the like. The control plane delivers the generated forwarding table to the forwarding plane. The forwarding chip 232 on the forwarding plane searches a table for and forwards, based on the forwarding table delivered by the control plane, a packet received by the network interface (not shown in the figure). The forwarding table delivered by the control plane is stored, for example, in a memory (not shown in the figure) on the line card. In some embodiments, the control plane and the forwarding plane may be deployed on different physical devices.)
Regarding claim 5, Hao in view of Thubert teach the method of claim 4, and is disclosed above, Hao further teaches wherein the service control plane comprises a distributed service control plane. (0193; Fig 7-9 showing control plane procedure between multiple devices and is therefore equivalent to distributed service control plane)
Regarding claim 6, Hao in view of Thubert teach the method of claim 3, and is disclosed above, Hao further teaches wherein distributing (delivering the forwarding table) the updated registration information (recording congestion information and state in the forwarding table) comprises directly distributing, by the service control plane (delivering by the control plane) to the plurality of ingress VOQs,(VOQ forwarding plane) the updated registration information (congestion information). ((0080; The control plane advertises and learns of a route, generates a forwarding table, processes signaling and a protocol packet, configures and maintains a device status, and the like. The control plane delivers the generated forwarding table to the forwarding plane. The forwarding chip 232 on the forwarding plane searches a table for and forwards, based on the forwarding table delivered by the control plane, a packet received by the network interface (not shown in the figure). The forwarding table delivered by the control plane is stored, for example, in a memory (not shown in the figure) on the line card. In some embodiments, the control plane and the forwarding plane may be deployed on different physical devices. (0032; receiving a second notification message from the second forwarding chip, where the second notification message indicates a congested state of the second outbound interface of the second forwarding chip; and recording the congested state of the second outbound interface based on the second notification message.) [0255] The forwarding chip 2 monitors a congested state of the interface 10 and a congested state of the interface 11. When the interface 10 of the forwarding chip 2 is congested, the forwarding chip 2 generates a notification message, and sends the notification message to a forwarding chip 1. The notification message includes a TB ID of the forwarding chip 2, a TP ID of the interface 10, and a congestion degree. After receiving the notification message sent by the forwarding chip 2, the forwarding chip 1 records a congested state of the interface 10 in a forwarding table.) ([0249] The uplink chip maintains a VOQ for each outbound interface. If an outbound interface of an inter-chassis interconnection link is congested, the switching chip back presses a congested state to the uplink chip. Consequently, packets in the VOQ queue are backlogged. The VOQ is an independent queue maintained by the chassis-shaped device for different outbound interfaces. The VOQ buffers ingress traffic before the ingress traffic enters the switching board, to avoid head-of-line (HOL) blocking. In a direction to an egress, a scheduler schedules a service flow corresponding to an ingress VOQ, and sends permitted credit values (credits) of different bandwidths to all service flows flowing to the egress, to accurately allocate a bandwidth based on a user service level agreement (SLA) and ensure quality of service (QOS). [0250] During route forwarding, the uplink chip determines a queue depth of the VOQ corresponding to the outbound interface. If the queue depth of the VOQ exceeds a configured threshold, the uplink chip determines that the outbound interface corresponding to the VOQ is congested. If there are a plurality of outbound interfaces of a shortest path, the uplink chip selects the remaining outbound interfaces of the shortest path for forwarding. If all outbound interfaces of the shortest path are congested, the uplink chip selects an outbound interface of a non-shortest path for forwarding.)
Regarding claim 7, Hao in view of Thubert teach the method of claim 1, and is disclosed above, Hao does not explicitly teach wherein the Clos configured backend network is configured in accordance with Locator ID Separation Protocol (LISP).
In an analogous art Thubert wherein the Clos configured backend network is configured in accordance with Locator ID Separation Protocol (LISP). ([0055] The example of FIG. 4 is optimized for the Clos/Fat tree fabric design, and takes advantage of that particular design to provide reliable multicast in a cheap and efficient fashion. [0065] The map server/resolver (e.g., LISP) 14 managing the fabric 100 can be updated of the status of the trees 104; [0066] FIG. 5 illustrates a variation of FIG. 4, where a management device (14 of FIG. 4) (e.g., executing a map server/map resolver (MSMR)) selecting a pair of trees to be used in the fabric for a particular multicast flow. In particular, the map server/map resolver (MSMR) ; [0078] As apparent from the foregoing, the example embodiments enable deployment of multiple redundant multicast trees in a fat tree topology, also referred to as a “CLOS” topology, for reliable delivery of multicast traffic.)
It would have been obvious to one of ordinary skill in the art prior to the effective filing of the application to modify the teachings of [Hao] to include [a Clos and Lisp configuration] as is taught by [Thubert].
The suggestion/motivation for doing so is to improve data packet distribution [0002-0007].
Regarding claim 8, Hao in view of Thubert teaches the method of claim 7, and is disclosed above, Hao does not explicitly teach but Thubert teaches wherein the service control plane comprises a distributed service control plane including one or more map resolvers (MRs) map servers (MSs) (MSMRs). ([0055] The example of FIG. 4 is optimized for the Clos/Fat tree fabric design, and takes advantage of that particular design to provide reliable multicast in a cheap and efficient fashion. [0065] The map server/resolver (e.g., LISP) 14 managing the fabric 100 can be updated of the status of the trees 104; [0066] FIG. 5 illustrates a variation of FIG. 4, where a management device (14 of FIG. 4) (e.g., executing a map server/map resolver (MSMR)) selecting a pair of trees to be used in the fabric for a particular multicast flow. In particular, the map server/map resolver (MSMR) ; [0078] As apparent from the foregoing, the example embodiments enable deployment of multiple redundant multicast trees in a fat tree topology, also referred to as a “CLOS” topology, for reliable delivery of multicast traffic.)
It would have been obvious to one of ordinary skill in the art prior to the effective filing of the application to modify the teachings of [Hao] to include [a distributed control plane with MSMRs] as is taught by [Thubert].
The suggestion/motivation for doing so is to improve data packet distribution [0002-0007].
Regarding claims 9-16, the claims inherit the same rejection as claim 1-8 above for reciting similar limitations in the form system claim. (0064-0067; system; 0279; processors; )
Regarding claims 17-20, the claims inherit the same rejection as claim 1-8 above for reciting similar limitations in the form a non-transitory computer readable media claim. (0049; 0278; 0284; computer readable storage media/memory storing instructions)
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABDERRAHMEN H CHOUAT whose telephone number is (571)431-0695. The examiner can normally be reached on Mon-Fri from 9AM to 5PM PST.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Christopher Parry, can be reached at telephone number 571-272-8328. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center to authorized users only. Should you have questions about access to the USPTO patent electronic filing system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
Examiner interviews are available via a variety of formats. See MPEP § 713.01. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) Form at https://www.uspto.gov/InterviewPractice.
Abderrahmen Chouat
Examiner
Art Unit 2451
/Chris Parry/Supervisory Patent Examiner, Art Unit 2451