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 .
The instant office action is in response to the Response to Election/Restriction communication of 04/29/26 indicating Group I being selected without traverse.
Claims 1-16 and 21-24 are pending of which claims 1, 9, and 21 are independent.
The IDS(s) of 11/30/2023 has been considered.
Internet Communications
Applicant is encouraged to submit a written authorization for Internet communications (PTO/SB/439, http://www.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.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1,3, 5, 6, 9, 11, 13, 14 , 21, and 23 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Narayanan et al (US 20250119436 A1).
Regarding claim 1, Narayanan discloses a method (i.e. Figs 1-12) implemented by a controller of a network(Fig. 2 the controller can be Network Access Device 220 or Central Controller 210 – see paragraphs 39 and 48), the method comprising: receiving, from a device of a user (Fig. 2 user device can be Laptop 230 or Cell Phone 240), first data packets (See paragraph 28 where data packets are transmitted between the end user devices of Fig. 2 and Network Access Device 130 and other network device 102 of Fig. 1 where the network traffic data associated with any particular application on the user device) associated with a first application (paragraphs 29 and 90 e.g. UDP Application but can be any Application) executing on the device (i.e. user devices of Fig. 2 being either laptop or cell phone), the first data packets comprising a first identifier and a device identifier (i.e. per paragraphs 30 and 35 the first identifier is GIT (Group Identifier Tag) and the device identifier can be source IP address for the source end user and destination IP address for the destination user device); identifying, based at least in part on the first identifier (i.e. GIT (Group Identifier Tag) paragraph 35) , a first user defined network (UDN) group within the network, the first UDN group comprising one or more second devices of the user (i.e. Per Fig. 6 the first UDN group has a GIT value of 333333 and has two end user devices and comprises an Admin Laptop and Camera.); applying, based at least in part on a first UDN identifier associated with the first UDN group, one or more policies to the first data packets (When a packet arrives at the Central Controller or Network Access Device forwarding policies are implemented based on the GIT (i.e. UDN) and assigned role as detailed in the abstract and paragraph 48. See Fig. 7 Rule 740 entry 1 saying any source to destination forwarding occurs by the Network Access Device if GIT matches meaning both source and destination are in the same UDN group. See also paragraphs 52 and 61) ; and sending, based at least in part on the one or more policies, the first data packets to each of the one or more second devices in the first UDN group.(i.e. given a UDN Group has one unique Id GIT (Group Identifier Tag) and per Figs. 4 and 7 rules entries at the Network Device packets from any source to destination is allowed as they have same GIT have to belong to the same UDN Group. The packet sending following this rule is shown in Figs. 2, 5, and 8. See paragraphs 55-59 and 63-68.)
Regarding claim 9, Narayanan discloses a system (Figs. 1-12 and in particular Figs 1 and 12 showing the system) comprising:
one or more processors (Fig. 12 processors 1204); and
one or more non-transitory computer-readable media (i.e. Main Memory 1206, ROM 1208, and Storage 1210 of Fig. 12 ) storing computer-executable
instructions that, when executed by the one or more processors, cause the one or more
processors to perform operations comprising:
receiving, from a device of a user (Fig. 2 user device can be Laptop 230 or Cell Phone 240), first data packets (See paragraph 28 where data packets are transmitted between the end user devices of Fig. 2 and Network Access Device 130 and other network device 102 of Fig. 1 where the network traffic data associated with any particular application on the user device) associated with a first application (paragraphs 29 and 90 e.g. UDP Application but can be any Application) executing on the device (i.e. user devices of Fig. 2 being either laptop or cell phone), the first data packets comprising a first identifier and a device identifier (i.e. per paragraphs 30 and 35 the first identifier is GIT (Group Identifier Tag) and the device identifier can be source IP address for the source end user and destination IP address for the destination user device); identifying, based at least in part on the first identifier (i.e. GIT (Group Identifier Tag) paragraph 35) , a first user defined network (UDN) group within the network, the first UDN group comprising one or more second devices of the user (i.e. Per Fig. 6 the first UDN group has a GIT value of 333333 and has two end user devices and comprises an Admin Laptop and Camera.); applying, based at least in part on a first UDN identifier associated with the first UDN group, one or more policies to the first data packets (When a packet arrives at the Central Controller or Network Access Device forwarding policies are implemented based on the GIT (i.e. UDN) and assigned role as detailed in the abstract and paragraph 48. See Fig. 7 Rule 740 entry 1 saying any source to destination forwarding occurs by the Network Access Device if GIT matches meaning both source and destination are in the same UDN group. See also paragraphs 52 and 61) ; and sending, based at least in part on the one or more policies, the first data packets to each of the one or more second devices in the first UDN group.(i.e. given a UDN Group has one unique Id GIT (Group Identifier Tag) and per Figs. 4 and 7 rules entries at the Network Device packets from any source to destination is allowed as they have same GIT have to belong to the same UDN Group. The packet sending following this rule is shown in Figs. 2, 5, and 8. See paragraphs 55-59 and 63-68.)
Regarding claim 21, Narayanan discloses one or more non-transitory computer-readable media (i.e. Main Memory 1206, ROM 1208, and Storage 1210 of Fig. 12 ) that when executed by one or more processors (Fig. 12 processors 1204) and cause the one or more processors to perform operations comprising:
receiving, from a device of a user (Fig. 2 user device can be Laptop 230 or Cell Phone 240), first data packets (See paragraph 28 where data packets are transmitted between the end user devices of Fig. 2 and Network Access Device 130 and other network device 102 of Fig. 1 where the network traffic data associated with any particular application on the user device) associated with a first application (paragraphs 29 and 90 e.g. UDP Application but can be any Application) executing on the device (i.e. user devices of Fig. 2 being either laptop or cell phone), the first data packets comprising a first identifier and a device identifier (i.e. per paragraphs 30 and 35 the first identifier is GIT (Group Identifier Tag) and the device identifier can be source IP address for the source end user and destination IP address for the destination user device); identifying, based at least in part on the first identifier (i.e. GIT (Group Identifier Tag) paragraph 35) , a first user defined network (UDN) group within the network, the first UDN group comprising one or more second devices of the user (i.e. Per Fig. 6 the first UDN group has a GIT value of 333333 and has two end user devices and comprises an Admin Laptop and Camera.); applying, based at least in part on a first UDN identifier associated with the first UDN group, one or more policies to the first data packets (When a packet arrives at the Central Controller or Network Access Device forwarding policies are implemented based on the GIT (i.e. UDN) and assigned role as detailed in the abstract and paragraph 48. See Fig. 7 Rule 740 entry 1 saying any source to destination forwarding occurs by the Network Access Device if GIT matches meaning both source and destination are in the same UDN group. See also paragraphs 52 and 61) ; and sending, based at least in part on the one or more policies, the first data packets to each of the one or more second devices in the first UDN group.(i.e. given a UDN Group has one unique Id GIT (Group Identifier Tag) and per Figs. 4 and 7 rules entries at the Network Device packets from any source to destination is allowed as they have same GIT have to belong to the same UDN Group. The packet sending following this rule is shown in Figs. 2, 5, and 8. See paragraphs 55-59 and 63-68.)
Regarding claim 3, Narayanan discloses the method of claim 1, wherein prior to receiving the first data packets, the method further comprising: receiving a request to connect to the network from the device of the user, the request including credentials; authenticating the credentials; and granting access to the network to the device. (See Fig. 1 credential data store 120 and group identifier tag data store 122 and see paragraphs 30 – 33 on receiving a request to connect to the network from the device of the user, the request including credentials; authenticating the credentials and paragraph 34 discloses granting access to the network to the network device)
Regarding Claim 5, Narayana discloses the method of claim 1, wherein applying the one or more policies (See Policy Rules in Fig. 4 as Rule 430 and Fig. 7 as Rule 740) comprises: identifying, based at least in part on first UDN identifier of the first UDN group, a traffic enforcement policy associated with the first UDN group (GIT is the UDN Group identifier see paragraph’s 35 and 38); determining, based at least in part on the first UDN identifier, that a destination of the first data packets corresponds to at least one of the one or more second devices (in the Rules 430 and 740 indicating if source and destination are in the same user defined group by having a matching same GIT then communication is allowed or else denied); and sending, based at least in part on the destination corresponding to at least one of the one or more second devices, the first data packets.(See Figs. 5 and 8 implementing the Rules)
Regarding Claim 6, Narayana discloses the method of claim 1, wherein applying the one or more policies(See Policy Rules in Fig. 4 as Rule 430 and Fig. 7 as Rule 740) comprises:
identifying, based at least in part on the first UDN identifier of the first UDN group, a traffic enforcement policy associated with the first UDN group; (GIT is the UDN Group identifier see paragraph’s 35 and 38);
determining, based at least in part on the first UDN identifier, that a destination of
the first data packets does not correspond to at least one of the one or more second devices; (in the Rules 430 and 740 indicating if source and destination are not in the same user defined group by having and do not have the same matching GIT then communication is allowed or else denied)and
refraining from sending the first data packets to the one or more second devices. (See paragraphs 21 and 44 on dropping the packets and refraining from sending the first data packets to the one or more second devices because they are not in the same user defined group sharing the same GIT as the source first devices.)
Regarding claim 11, claim 11 is rejected in the same scope as claim 3.
Regarding claim 23, claim 23 is rejected in the same scope as claim 3.
Regarding claim 13, claim 13 is rejected in the same scope as claim 5.
Regarding claim 14, claim 14 is rejected in the same scope as claim 6.
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) 2, 4, 10, 22, and 24 is/are rejected under 35 U.S.C. 103 as being unpatentable over Narayanan in view Peng et al (US 20250062995 A1).
Regarding Claim 2, Narayanan discloses the method of claim 1, but fails to disclose, wherein prior to receiving the first data packets, the method further comprising: receiving, from an authentication, accounting, and authorization engine, data indicating a mapping of the first application to the first identifier associated with the first UDN group; storing the mapping in memory; and sending, to the device of the user, the data indicating the mapping.
Peng, in the same endeavor, discloses wherein prior to receiving the first data packets, the method further comprising: receiving, from an authentication, accounting, and authorization engine, data indicating a mapping of the first application to the first identifier associated with the first UDN group; storing the mapping in memory; and sending, to the device of the user, the data indicating the mapping. (See Fig. 1 where the first device receives an Application Aware ID and per Fig. 6 and paragraph 155 the Application 11 is associated with the user group domain name 1 and the DNS server 20 provides an authentication, accounting, and authorization engine, data indicating a mapping of the first application to the first identifier associated with the first UDN group of domain name 1 per paragraph 150.)
In view of the above, having Narayana’s UDN group and then given the well- established teaching of Peng’s techniques for configuring application to an identifier, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention was made to modify Narayana’s UDN group as taught by of Peng’s techniques for configuring application to an identifier, since Peng states in paragraph 6 that the modification results in improving user experience brought by the application to a user.
Regarding claim 10, claim 10 is rejected in the same scope as claim 2.
Regarding claim 22, claim 22 is rejected in the same scope as claim 4.
Regarding claim 4, Narayanan discloses the method of claim 1, but fails to disclose, wherein the first identifier comprises a flow label, and wherein identifying the first UDN group within the network is based at least in part on identifying a mapping of the device identifier and the flow label to the first UDN identifier of the first UDN group.
Peng, in the same endeavor, discloses wherein the first identifier comprises a flow label, and wherein identifying the first UDN group within the network is based at least in part on identifying a mapping of the device identifier and the flow label to the first UDN identifier of the first UDN group. (See paragraphs 24 and 27 indicating the first application-aware networking identifier is an APN ID corresponding to the first application, and the APN ID may include, for example, at least one of the following information: an APP GROUP ID, a USER GROUP ID, a FLOW ID, or an SLA.)
In view of the above, having Narayana’s UDN group and then given the well- established teaching of Peng’s techniques for configuring application flow label to an identifier, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention was made to modify Narayana’s UDN group as taught by of Peng’s techniques for configuring application flow label to an identifier, since Peng states in paragraph 6 that the modification results in improving user experience brought by the application to a user.
Regarding claim 12, claim 12 is rejected in the same scope as claim 4.
Regarding claim 24, claim 24 is rejected in the same scope as claim 4.
Allowable Subject Matter
Claims 7, 8, 15, and 16 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HABTE MERED whose telephone number is (571)272-6046. The examiner can normally be reached Monday - Friday 12-10 PM EST.
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, Michael Thier can be reached at 5712722832. 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.
/HABTE MERED/Primary Examiner, Art Unit 2474
Prosecution Insights