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
Continued Examination Under 37 CFR 1.114
A request for continued examination (RCE) under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed on 02/19/2026 in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant’s submission filed on 02/06/2026 has been entered.
As per instant Amendment, claims 1, 4-5, 9-11 and 16 have been amended; Claims 1, 11 and 16 are independent claims. Claims 1-20 have been examined and are pending. This Action is made Non-FINAL.
Response to Arguments
The rejections of claims 1-10 under 35 U.S.C. § 101 are withdrawn as the claims have been amended.
Applicants’ arguments with respect to claims 1-20 have been considered but are moot in view of the new ground(s) of rejection.
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 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 of this title, 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-20 are rejected under 35 U.S.C. 103 as being unpatentable over Sharifi (US 10,103,878), in view of Zhang (CN 117521141) and further in view of Wijnands (US 7, 529, 199).
Regarding claim 1, Sharifi discloses a system comprising a network appliance comprising:
a memory storing instructions; and
one or more processing resources coupled to the memory to execute the instructions to:
receive network traffic from a client device to receive network traffic from a client device (Sharifi col. 7; lines 57-61; For example, a gateway may receive encrypted network traffic on two separate ports and then forward the encrypted traffic onto the primary authentication service 215 and the secondary authentication service 218), transmit an access grant request to an external server to determine access status of the client device to an end node associated with a service (Sharifi col. 7; lines 62-67; An authentication request 242 (FIG. 2) in association with the unique identifier 236. The authentication request 242 may be transmitted in an encrypted container, e.g., by SSL, TLS, etc. Multiple other security credentials relating to different authentication factors may be sent to multiple secondary authentication services 218 in some implementations), receive an access token indicating that the client device has access to the service (Sharifi col. 8; lines 13-18; If the authentication is successful, the client application 251 receives a session token 227 (FIG. 2) from the primary authentication service 215 in box 524. The client application 251 may then access secured resources and/or personalization by presenting the session token 227 during a session).
Sharifi teaches transmitting the authentication request and receive an access token indicating that the client device has access to the service (Sharifi col. 7; lines 57-67 and col. 8; lines 13-18). However, Sharifi does not explicitly disclose generate one or more forwarding path rules specifying how to route the network traffic along a path of nodes to a destination node upon receiving the access token.
However, in an analogous art, Zhang discloses generate one or more forwarding path rules upon receiving the access token (Zhang par. n 0076-n0079 ( Step 203-205); According to the authorization record, the file access authority control system respectively takes the authorization identity token, the access path corresponding to the authorization file and the authorization overdue time as the key of the ZSet ordered set data structure. The authorization identity token. Token is used as the key, the access path corresponding to the authorization file is used as the value member, the authorization expiration time is used as the score, storing the user file access authority authorization record in the distributed cache Redis according to the zset ordered set data structure, and according to the agreed rule (authorization file and the access path corresponding to the authorization file), generating FastDFS (an open source lightweight distributed file system developed in C language) authorization file access link, then in the user Cookies of the service system, adding the token record field for recording the user identity token, for example, defining the identity token generated when the "file-auth-token" field user records the service logging in the service system, then using the file-auth-token as the key).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify the generate one or more forwarding path rules based on authorization tokens of Sharifi using the generate one or more forwarding path rules based on authorization tokens taught in Zhang in order to provide users with a means for controlling authorization file access link that a user initiates a file access request (Zhang step 205).
Sharifi and Zhang teaches transmitting the authentication request and receive an access token indicating that the client device has access to the service (Sharifi col. 7; lines 57-67 and col. 8; lines 13-18) and generate one or more forwarding path rules based on authorization tokens (Zhang par. n 0076-n0079 (Step 203-205). However, Sharifi and Zhang do not explicitly disclose path rules specifying how to route the network traffic along a path of nodes to a destination node upon receiving the access token.
However, in an analogous art, Wijnands discloses path rules specifying how to route the network traffic along a path of nodes to a destination node upon receiving the access token (Wijnands col. 7; lines 34-47; The policy can specify that the route information with the highest edge node identifier is the route information to select. If each piece of route information includes several node identifiers Nn, N(n-1), . . . N1, where Nn is the edge node closest to the root of the tree and N1 is the core node closest to the edge node that generated the route information, the policy can select the route information with the highest Nn. If multiple pieces of route information have the same Nn, the policy can select the one with the highest N(n-1), and so on. If the network has redundant paths, then the policy can be configured to select among the node identifiers in a way that gives preference to certain paths and/or nodes. See also col. 5; lines 11-21).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify the generated one or more forwarding path rules of Sharifi and Zhang using path rules specifying how to route the network traffic to a destination taught in Wijnands in order to select a policy that selects route information based on the node identifiers that are included in the route information (Wijnands col. 7; lines 29-32).
Regarding claim 2, Sharifi, Zhang and Wijnands disclose the system of claim 1,
Zhang further discloses wherein the network appliance installs a network access policy and session based on the one or more forwarding path rules (Zhang par. n 0076-n0079 ( Step 203-205); According to the authorization record, the file access authority control system respectively takes the authorization identity token, the access path corresponding to the authorization file and the authorization overdue time as the key of the ZSet ordered set data structure. The authorization identity token. Token is used as the key, the access path corresponding to the authorization file is used as the value member, the authorization expiration time is used as the score, storing the user file access authority authorization record in the distributed cache Redis according to the zset ordered set data structure, and according to the agreed rule (authorization file and the access path corresponding to the authorization file)).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify the generate one or more forwarding path rules based on authorization tokens of Sharifi and Wijnands using the generate one or more forwarding path rules based on authorization tokens taught in Zhang in order to provide users with a means for controlling authorization file access link that a user initiates a file access request (Zhang step 205).
Regarding claim 3, Sharifi, Zhang and Wijnands disclose the system of claim 2,
Sharifi further discloses wherein the network appliance forwards the network traffic through the network appliance using the policy and session (Sharifi col. 8; lines 13-18; If the authentication is successful, the client application 251 receives a session token 227 (FIG. 2) from the primary authentication service 215 in box 524. The client application 251 may then access secured resources and/or personalization by presenting the session token 227 during a session).
Regarding claim 4, Sharifi, Zhang and Wijnands disclose the system of claim 2,
Zhang further discloses wherein the network appliance sets a timer upon installation of the policy and the session and removes the policy and the session upon expiration of the timer (Zhang par. n0078-n0079; The overdue time of 2 hours is set for the access right of the authorization file. At the same time, the authorization identity token Token is used as the key, the access path corresponding to the authorization file is used as the value member, the authorization expiration time is used as the score, storing the user file access authority authorization record in the distributed cache Redis according to the zset ordered set data structure, and according to the agreed rule (authorization file and the access path corresponding to the authorization file)).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify the generate one or more forwarding path rules based on authorization tokens of Sharifi and Wijnands using the generate one or more forwarding path rules based on authorization tokens taught in Zhang in order to provide users with a means for controlling authorization file access link that a user initiates a file access request (Zhang step 205).
Regarding claim 5, Sharifi, Zhang and Wijnands disclose the system of claim 1,
Sharifi further discloses wherein the access grant request is transmitted to the external server via an Out-of-band (OOB) interface (Sharifi col. 8; lines 20-36; Although the above discussion assumes that the client application 251 is installed on a single client device 206, the flowchart of FIG. 5 may be performed by client applications 251 executed on separate client devices 206. For example, the first security credential may be received via a user interface 254 on a first client device 206, while the second security credential may be received via a user interface 254 on a second client device 206. The first client device 206 would then send the first security credential to the primary authentication service 215, while the second client device 206 would send the second security credential to the secondary authentication service 218. The unique identifier 236 may be shared among the client devices 206, and in some cases the unique identifier 236 may be securely generated by one of the client devices 206. The session token 227 could be received by one of the client devices 206 and then shared with the other client devices 20).
Regarding claim 6, Sharifi, Zhang and Wijnands disclose the system of claim 2,
Sharifi further discloses wherein the network appliance determines whether a second network appliance is in a path to the service, generates an access message including the access token upon determining that the second network appliance is in the path and transmits the access message to a second network appliance (Sharifi col. 11; lines 61-67 and col. 12; lines 1-5; For example, the order of execution of two or more blocks may be scrambled relative to the order shown. Also, two or more blocks shown in succession in FIGS. 4-7 may be executed concurrently or with partial concurrence. Further, in some embodiments, one or more of the blocks shown in FIGS. 4-7 may be skipped or omitted. In addition, any number of counters, state variables, warning semaphores, or messages might be added to the logical flow described herein, for purposes of enhanced utility, accounting, performance measurement, or providing troubleshooting aids, etc. It is understood that all such variations are within the scope of the present disclosure).
Regarding claim 7, Sharifi, Zhang and Wijnands disclose the system of claim 6,
Sharifi further discloses wherein the second network appliance to receive the access message, verify a second forwarding path rule upon verification of the authorization token and install a second network access policy and session based on the second forwarding path rule to allow the client traffic through the second network appliance (Sharifi col. 7; lines 48-67 and col. 8; lines 1-6; The client application 251 sends a second security credential such as a password to the secondary authentication service 218 (FIG. 2) via the network 209. The data may be sent by the client application 251 to a second network address associated with the secondary authentication service 218. In one scenario, the first and second network addresses may comprise different internet protocol (IP) addresses. In another scenario, the first and second network addresses may comprise the same IP address but with a different port identifier. For example, a gateway may receive encrypted network traffic on two separate ports and then forward the encrypted traffic onto the primary authentication service 215 and the secondary authentication service 218. The second security credential may be sent in an authentication request 242 (FIG. 2) in association with the unique identifier 236. The authentication request 242 may be transmitted in an encrypted container, e.g., by SSL, TLS, etc. Multiple other security credentials relating to different authentication factors may be sent to multiple secondary authentication services 218 in some implementations. Further, in some situations, different portions of a security credential may be sent to different secondary authentication services 218. For example, the first four characters of a password may be sent to one secondary authentication service 218, while the remaining characters of the password may be sent to another secondary authentication service 218).
Regarding claim 8, Sharifi, Zhang and Wijnands disclose the system of claim 7,
Sharifi further discloses wherein the second network appliance generates a second access message including the access token and transmits the second access message to a third network appliance (Sharifi col. 8; lines 13-18; If the authentication is successful, the client application 251 receives a session token 227 (FIG. 2) from the primary authentication service 215 in box 524. The client application 251 may then access secured resources and/or personalization by presenting the session token 227 during a session).
Regarding claim 9, Sharifi, Zhang and Wijnands disclose the system of claim 1,
Sharifi further discloses wherein the network appliance determines whether an IP address included in the network traffic associated with the client is recognized, transmits the access grant request to the external server upon determining that the IP address is not recognized and forwards the network traffic is upon determining that the IP address is recognized (Sharifi col. 7; lines 53-65; In one scenario, the first and second network addresses may comprise different internet protocol (IP) addresses. In another scenario, the first and second network addresses may comprise the same IP address but with a different port identifier. For example, a gateway may receive encrypted network traffic on two separate ports and then forward the encrypted traffic onto the primary authentication service 215 and the secondary authentication service 218. The second security credential may be sent in an authentication request 242 (FIG. 2) in association with the unique identifier 236. The authentication request 242 may be transmitted in an encrypted container, e.g., by SSL, TLS, etc. Multiple other security credentials relating to different authentication factors may be sent to multiple secondary authentication services 218 in some implementations).
Regarding claim 10, Sharifi, Zhang and Wijnands disclose the system of claim 1,
Sharifi further discloses wherein the network traffic is blocked upon a determination that no token has been received (Sharifi col. 7; lines 13-19; If the authentication is successful, the client application 251 receives a session token 227 (FIG. 2) from the primary authentication service 215 in box 524. The client application 251 may then access secured resources and/or personalizations by presenting the session token 227 during a session. Thereafter, the portion of the client application 251 ends).
Regarding claims 11-15; claims 11-15 are directed to a method associated with the system claimed in claims 1-5 respectively. Claims 11-15 are similar in scope to claims 1-5 respectively, and are therefore rejected under similar rationale respectively.
Regarding claims 16-20; claims 16-20 are directed to a non-transitory computer readable medium associated with the system claimed in claims 1-5 respectively. Claims 16-20 are similar in scope to claims 1-5 respectively, and are therefore rejected under similar rationale respectively.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SANCHIT K SARKER whose telephone number is (571)270-7907. The examiner can normally be reached M-F 8:30 AM-5:30 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, FARID HOMAYOUNMEHR can be reached at 571-272-3739. 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.
/SANCHIT K SARKER/Primary Examiner, Art Unit 2495