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 .
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 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.
This office action is in response to the communication filed on 02/05/2026.
Claims 1-5, 9-13, 16, 21-29 are pending.
Response to Arguments
Applicant’s arguments have been considered but found moot in view of new ground(s) of rejection.
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.
Claim(s) 1-4, 10-12, 21-24 is/are rejected under AIA 35 U.S.C. 103 as being unpatentable over Droms et al. (US 7,143,435 B1, “Droms”) in view of Shatzkamer et al. (US 2008/0279200, “Shatzkamer”) and Chang et al. (US 2012/0272289, “Chang”).
For claim 1, Droms discloses a system comprising:
a microprocessor; and a computer readable medium, coupled with the microprocessor and comprising microprocessor readable and executable instructions that, when executed by the microprocessor (fig. 6), cause the microprocessor to:
receive a request to authenticate, wherein the request to authenticate has an associated address (fig. 1, 5B, col. 16, l. 34-47, col. 9, par. 2, a DHCP server (registration server in fig. 5B) receives a request to authenticate a particular IP address);
validate the request to authenticate (fig. 5B, col. 16, l. 57-61, the DHCP server identifies a mapping (map 114) according to a registered IP address, together with a user group of the user of host 122); and
in response to validating the request to authenticate, send a first message to a routing device that identifies the associated address as authenticated for routing packets (fig. 5B, col. 16, last par., the DHCP server after successfully locating a registered IP address, sends the IP address and the user group to the gateway which will allow/provide or deny its service, e.g., Internet access, to the client);
get a list of authenticated addresses (Droms, fig. 5B, step 574).
Droms discloses the request to authenticate is for a user (fig. 5B, col. 16, l. 57-61, the DHCP server identifies a mapping (map 114) according to a registered IP address, together with a user group of the user of host 122)
Droms does not disclose the microprocessor readable and executable instructions further cause the microprocessor to: detect that the user has logged out; and in response to detecting that the user has logged out, send a second message to the routing device that identifies that the associated address as invalid for routing the packets.
Shatzkamer discloses the microprocessor readable and executable instructions further cause the microprocessor to: detect that the user has logged out; and in response to detecting that the user has logged out, send a second message to the routing device that identifies that the associated address as invalid for routing the packets (fig. 4, [0077], [0078], when the user ID signs off from an AAA server, the IP address of the user ID is disassociated from a user URI profile used for routing packets (required in fig. 6) or therefore disabling routing of packets from the IP address to at least URIs in the user URI profile at a gateway; fig. 6, for packets to be routed by the gateway, the user ID has to be authenticated, signed on (fig. 6, step 602), a user URI profile is then retrieved (step 610) and the packets are routed based on the user URI profile (step 642). When a user ID signs off, the user’s IP address is disassociated from the user URI profile (by marking the IP address in the user cache obsolete or unusable) and then the method in fig. 6 returns to step 602, disabling any routing of the packets from the IP address to URIs pass the gateway).
It would have been obvious to one skilled in the art before the effective filing date of the claimed invention to apply Shatzkamer’s teachings of invalidating packet routing at a gateway for a user who has logged off to Droms’s system also containing a gateway and a RADIUS server (fig. 1) in order to ensure that the user is still signed-in and authenticated to be provided service access (local network or Internet).
Droms-Shatzkamer does not disclose instructions to monitor a network for use of one or more non-approved addresses; identify use of the one or more non-approved addresses on the network; and in response to identifying the use of the one or more non-approved addresses, take an action such as automatically bring up a graphical user interface, shutdown the network device, shutdown an application, quarantine the application, quarantine a device, initiate a virus scan, open up a network management system or display statistics associated with the associated address.
Chang discloses instructions to monitor a network for use of one or more non-approved addresses; identify use of the one or more non-approved addresses on the network; and in response to identifying the use of the one or more non-approved addresses, take an action such as automatically bring up a graphical user interface, shutdown the network device, shutdown an application, quarantine the application, quarantine a device, initiate a virus scan, open up a network management system or display statistics associated with the associated address ([0255], detecting a use of a blocked source address and generate a user alert via a user interface)
It would have been obvious to one skilled in the art before the effective filing date of the claimed invention to apply Chang’s teachings of rules-based security actions when detecting a blocked source address to Droms-Shatzkamer’s system in order implement a plurality of security measures for Droms’s system (Chang, [0255]).
For claim 2, Droms discloses the request to authenticate is based on a plurality of authentication levels associated with the user, wherein a first authentication level of the plurality of authentication levels causes the first message to be sent to the routing device within a private network (fig. 1, col. 8, l. 8-37, sending authorization information with a user class with a first privilege (LAN access) to the switch to enable LAN access), and wherein a second authentication level of the plurality of authentication levels causes the first message to be sent to the routing device within the private network (fig. 1, col. 8, l. 8-37, sending authorization information with a user class with a second privilege (LAN access and Internet access) to the switch to enable LAN access) and to a firewall connected to an external network (fig. 1, col. 8, l. 8-37, col. 16, last par., sending authorization information with a user class with a second privilege (LAN access and Internet access) to the switch 102 to enable LAN access, and a message to the gateway 142 to enable Internet access).
For claim 3, Droms discloses the associated address is an Internet Protocol (IP) address a provided by a Dynamic Host Configuration Protocol (DHCP) server (col. 16, last 3 paragraphs).
For claim 4, Droms discloses the IP address is not provided until the user logs in locally to a communication device (col. 9, l. 46-67, user logs in with username/password to a device to be authenticated a RADIUS server).
Claims 10-12 are rejected for the same rationale in claims 1-3 respectively.
Claims 21-24 are rejected for the same rationale in claims 1-4 respectively.
Claim(s) 5, 13, 25 is/are rejected under AIA 35 U.S.C. 103 as being unpatentable over Droms-Shatzkamer-Chang in view of Khandani (US 2020/0366468).
For claims 5, 13, 25, Droms-Shatzkamer-Chang does not disclose the associated address comprises at least one of: an Internet Packet Exchange (IPX) address, a Media Access Control (MAC) address, a transport layer application address, a presentation layer address, an application layer address, a port number of an application, a Q.931 address, a Uniform Resource Locator (URL), a H.323 address, and a Session Initiation Protocol (SIP) address.
Khandani discloses the associated address comprises at least one of: an Internet Packet Exchange (IPX) address, a Media Access Control (MAC) address, a transport layer application address, a presentation layer address, an application layer address, a port number of an application, a Q.931 address, a Uniform Resource Locator (URL), a H.323 address, and a Session Initiation Protocol (SIP) address ([0130], request for authentication including a MAC address from a client device).
It would have been obvious to one skilled in the art before the effective filing date of the claimed invention to apply Khandani’s teachings of MAC address authentication to Droms-Shatzkamer-Chang’s system in order to implement an alternative authentication of MAC address instead of IP address.
Claim(s) 9, 16, 26 is/are rejected under AIA 35 U.S.C. 103 as being unpatentable over Droms-Shatzkamer-Chang in view of Grothendieck et al. (US 2019/0327252, “Grothendieck”).
For claims 9, 16, 26, Droms-Shatzkamer-Chang discloses the request to authenticate is for the user (Droms, fig. 5B, col. 16, l. 57-61, the DHCP server identifies a mapping (map 114) according to a registered IP address, together with a user group of the user of host 122)
Droms-Shatzkamer-Chang does not disclose the microprocessor readable and executable instructions further cause the microprocessor to: identify a usage pattern of authenticated addresses by the user using machine learning; identify a change to the usage pattern as an anomalous behavior; and in response to identifying the usage pattern as an anomalous behavior, take an action.
Grothendieck discloses instructions to identify a usage pattern of authenticated addresses by the user using machine learning; identify a change to the usage pattern as an anomalous behavior; and in response to identifying the usage pattern as an anomalous behavior, take an action ([0042], [0043], using machine learning to detect discordant activities (a change in usage pattern) associated with a source IP address, which is allowed or authenticated to communicate over a specified time; detected discordant activities will activate an action such as an alert).
It would have been obvious to one skilled in the art before the effective filing date of the claimed invention to apply Grothendieck’s teachings of machine learning for identifying discordant behavior to Droms-Shatzkamer-Chang’s system in order to improve the system by automatically detecting unusual or harmful activities by machine learning (Grothendieck, [0019]).
Claim(s) 27-29 is/are rejected under AIA 35 U.S.C. 103 as being unpatentable over Droms-Shatzkamer-Chang in view of Seine et al. (US 2017/0180305, “Seine”).
For claims 27-29, Droms discloses the associated address comprises an assigned Internet Protocol (IP) address originating from the request to authenticate and supplied by a requesting device (fig. 1, 5B, col. 16, l. 34-47, col. 9, par. 2, a DHCP server (registration server in fig. 5B) receives a request to authenticate a particular IP address of a host)
Droms-Shatzkamer-Chang does not disclose the IP address is a static IP address.
Seine discloses a static IP address ([0013], [0039], [0040], [0049]).
It would have been obvious to one skilled in the art before the effective filing date of the claimed invention to apply Seine’s teachings of static IP address to Droms-Shatzkamer-Chang’s system in order to implement an alternative of Droms’s auto-configured IP addresses as static IP addresses (Seine, ([0013], [0039], [0040], [0049]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HIEU T HOANG whose telephone number is (571) 270-1253. The examiner can normally be reached Mon-Fri 9 AM -5 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, Vivek Srivastava can be reached on 571-272-7304. 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.
/HIEU T HOANG/Primary Examiner, Art Unit 2449
Prosecution Insights