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 .
DETAILED ACTION
Election/Restrictions
Applicant’s election without traverse of Group I (Claims 1-18) in the reply filed on 9/16/2026 is acknowledged.
This is a reply to the application filed on 9/16/2026, in which claim(s) 1-18 and 21-22 are pending.
Claim(s) 19-20 is/are cancelled.
Claim(s) 21-22 is/are newly added.
Specification
The lengthy specification has not been checked to the extent necessary to determine the presence of all possible minor errors. Applicant’s cooperation is requested in correcting any errors of which applicant may become aware in the specification.
Drawings
The drawings filed on 3/31/2025 is/are accepted by The Examiner.
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-18 and 21-22 is/are rejected under 35 U.S.C. 103 as being unpatentable over Singhvi et al. (US 20220239654 A1; hereinafter Singhvi) in view of Mittal et al. (US 20210218774 A1; hereinafter Mittal).
Regarding claims 1, 10 and 21, Singhvi discloses a method performed by a network device, the method comprising:
receiving a data packet on an interface of the network device (receiving incoming payload at the network device [Singhvi; ¶33-34, 52-59; Fig. 3 and associated texts]);
upon determining that the interface is configured with 802.1X authentication and has both Extensible Authentication Protocol-based authentication (EAP) and Media Access Control-based authentication (MBA) enabled[[, tagging the data packet with a first label]] (network device performs an initial EAPol or MAC-based authentication of a host, authenticate a user in various manners including in accordance with the IEEE 802.1X protocol—Extensible Authentication Protocol over Local Area Network (EAPoL) or media access control address (MAC)-based authentication [Singhvi; ¶33-34, 52-59; Fig. 3 and associated texts]); and
upon determining that the interface is configured with 802.1X authentication and has only Extensible Authentication Protocol-based authentication (EAP) enabled[[, tagging the data packet with a second label different from the first label]] (network device performs an initial EAPol or MAC-based authentication of a host, authenticate a user in various manners including in accordance with the IEEE 802.1X protocol—Extensible Authentication Protocol over Local Area Network (EAPoL) or media access control address (MAC)-based authentication [Singhvi; ¶33-34, 52-59; Fig. 3 and associated texts]). Singhi does not explicilty disclose tagging the data packet with a first label and tagging the data packet with a second label different from the first label; however, in a related and analogous art, Mittal teaches this feature.
In particular, Mittal teaches packets can be intercepted by tagging or otherwise associating the packets with group IDs and then triggering rules based on the group IDs for processing the packets, the forwarding logic can associate a group ID with the packet. The group ID is associated with the packet but is not otherwise part of the content that comprises the packet. The associated group ID can then be used to identify a rule to determine how to process/forward the packet [Mittal; ¶18-244; Figs. 5, 7 and associated texts]. It would have been obvious before the effective filing date of the claimed invention to modify Singhvi in view of Mittal packet tagging with the motivation to better forward the packet associated with matched rules are applied to the outgoing packets [Mittal; Abstract].
Regarding claims 2, 11 and 22, Singhvi-Mittal combination discloses wherein a ternary-content addressable memory (TCAM) of the network device is programmed with:
a first TCAM rule including a first match key that matches on the first label and a first action that traps matched packets to a central processing unit (CPU) of the network device (incoming frame is trapped by the network device hardware of the network device based on satisfying certain policies. For example, the incoming frame may be trapped based on one or more permit and deny rules of a unified ACL [Singhvi; ¶52-67; Fig. 3 and associated texts]); and
a second TCAM rule including a second match key that matches on the second label and a second action that drops matched packets (ACL enforcer includes a ternary content-addressable memory (TCAM) and the custom redirect rule is programmed into the TCAM by the ACL enforcer. Indeed, in the foregoing embodiment, when any unified ACL rule matches the incoming frame, the matching rule may be programmed into the TCAM by the ACL enforcer [Singhvi; ¶52-67; Fig. 3 and associated texts]).
Regarding claims 3 and 12, Singhvi-Mittal combination discloses wherein the first and second TCAM rules have lower priority than other TCAM rules in the TCAM that allow traffic from authenticated hosts (rules goes by level [Singhvi; ¶9, 48-49; Fig. 3 and associated texts]).
Regarding claims 4 and 13, Singhvi-Mittal combination discloses wherein the data packet originated from an unauthenticated host (unauthorized host [Singhvi; ¶52-67; Fig. 3 and associated texts]).
Regarding claims 5 and 14, Singhvi-Mittal combination discloses wherein, in a first scenario where the interface is configured with 802.1X authentication and has both EAP and MBA enabled, the method further comprises: matching the data packet to the first TCAM rule, thereby causing the data packet to be trapped to the CPU in accordance with the first action (incoming frame is trapped by the network device hardware of the network device based on satisfying certain policies. For example, the incoming frame may be trapped based on one or more permit and deny rules of a unified ACL, ACL enforcer includes a ternary content-addressable memory (TCAM) and the custom redirect rule is programmed into the TCAM by the ACL enforcer. Indeed, in the foregoing embodiment, when any unified ACL rule matches the incoming frame, the matching rule may be programmed into the TCAM by the ACL enforcer [Singhvi; ¶52-67; Fig. 3 and associated texts]).
Regarding claims 6 and 15, Singhvi-Mittal combination discloses in a second scenario where the interface is configured with 802.1X authentication and has only EAP enabled, the method further comprises: matching the data packet to the second TCAM rule, thereby causing the data packet to be dropped in accordance with the second action (drop the incoming network traffic [Singhvi; ¶52-67; Fig. 3 and associated texts]).
Regarding claims 7 and 16, Singhvi-Mittal combination discloses further comprising: upon determining that the interface is not configured with 802.1X authentication, tagging the data packet with a third label different from the first and second labels(IEEE 802.1X industry-adopted protocol, for example, requires user authentication prior to granting the user access to certain websites; otherwise, all but a select number of internal websites are considered off-limits to an unauthenticated user, the authentication server may implement further functionality such as initiating an authentication session to authenticate a host, a network device to facilitate such authentication, and receiving authentication status from a captive portal [Singhvi; ¶33-34, 52-67; Fig. 3 and associated texts]).
Regarding claims 8 and 17, Singhvi-Mittal combination discloses wherein the data packet originated from an authenticated host and wherein the data packet is not matched to either the first TCAM rule or the second TCAM rule (In response to finding no match between the user authentication credentials and the database of captive portal authentications, a user is blocked from full access to the network [Singhvi; ¶31-34, 52-67; Fig. 3 and associated texts]).
Regarding claims 9 and 18, Singhvi-Mittal combination discloses wherein the network device is an authenticator device that communicates with an authentication server to implement 802.1X authentication accordance with the IEEE 802.1X protocol [Singhvi; ¶33-34, 52-59; Fig. 3 and associated texts]).
Internet Communications
Applicant is encouraged to submit a written authorization for Internet communications (PTO/SB/439, http:ljwww.uspto.gov/sites/default/files/documents/sb0439.pdf) in the instant patent application to authorize the examiner to communicate with the applicant via email. The authorization will allow the examiner to better practice compact prosecution. The written authorization can be submitted via one of the following methods only: (1) Central Fax which can be found in the Conclusion section of this Office action; (2) regular postal mail; (3) EFS WEB; or (4) the service window on the Alexandria campus. EFS web is the recommended way to submit the form since this allows the form to be entered into the file wrapper within the same day (system dependent). Written authorization submitted via other methods, such as direct fax to the examiner or email, will not be accepted. See MPEP § 502.03.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DAO Q HO whose telephone number is (571)270-5998. The examiner can normally be reached on 7:00am - 5:00pm.
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, Jeffrey Nickerson can be reached on (469) 295-9235. 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 the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/DAO Q HO/Primary Examiner, Art Unit 2432
