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 .
This communication is in response to the application filed 03/27/2025. Claims 1-20 are rejected.
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.
Claims 1-4, 7-11, 14-18, 20 are rejected under 35 U.S.C. 103 as being unpatentable over Hulse et al. (US 20140245395 A1), hereafter Hulse in view of Calvert et al. (US 20190188934 A1), hereafter Calvert.
Regarding claim 1, Hulse teaches a method comprising:
receiving, by an application programming interface (API) portal, a first request from a user device to connect to a transmission control protocol (TCP) transport layer of a server ([0060] a communication request is received at the on-site router from a user device for communication external to the site-based network);
authenticating, by the API portal, the user device based on the first request ([0060] a determination is made as to whether the user device is authorized to communicate as requested over the Internet. This involves the on-site router making a route or forward determination according to whether the user device is listed in its route map as an authorized user device);
providing, by the API portal, to the server, based on the authenticating, a second request to access to a TCP port of the server ([0060] If it is determined that the user device is already authorized to communicate as requested over the Internet (e.g., the user device is included in the on-site router's ACL), the communication can be routed to the destination address associated with the communication request);
receiving, by the API portal, from the server, a response to the second request, indicating that the user device is permitted to access the TCP port ([0062] a response is received from the off-site authentication system that includes a captive authentication portal that permits the user device to become authorized to communicate as requested over the Internet. Examiner note: The off-site using cloud-based servers that connect to internet, they are include TCP ports as obviously); and
Hulse does not explicitly teach
sending, by the API portal, to the user device, a response to the first request, the response to the first request indicating that the user device is permitted to access the TCP port.
Calvert teaches
sending, by the API portal, to the user device, a response to the first request, the response to the first request indicating that the user device is permitted to access the TCP port ([0064] The server may be configured to generate an access determination, based on the authorization information, indicative of whether the user device is authorized to access a secure function of a secure device; [0067] the network device may be configured to receive the access determination from the server via the external network).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention made to include in the Hulse disclosure, an authorization information response from the server, as taught by Calvert. One would be motivated to do so for secure access and access control applications to indicative of whether the user of the mobile device is authorized to access the secure function.
Regarding claims 2, 9, 16, Hulse and Calvert teach all limitations of parent claims 1, 8, and 15, wherein Hulse further teaches the first request specifies the TCP port ([0004] As the off-site authentication system authenticates devices (e.g., via an interactive captive authentication portal), the off-site authentication system can remotely update the appropriate route maps of the on-site routers at the various sites to add those devices).
Regarding claims 3, 10, and 17, Hulse and Calvert teach all limitations of parent claims 1, 8, and 15, wherein Hulse further teaches the first request does not specify the TCP port ([0053] the user executes an application that automatically looks for a connection to the Internet), and wherein the response to the second request and the response to the first request specify the TCP port ([0055] forwards the communication to an off-site authentication system for authentication of the user device).
Regarding claims 4, 11, and 18, Hulse and Calvert teach all limitations of parent claims 1, 8, and 15, Hulse further teaches:
attaching a TCP transport layer daemon to the TCP port in response to the second request ([0024] When a user connects a user device to the site-based network, the on-site router detects the connection and issues an IP address and other common network settings to the user device).
Regarding claims 7, 14, and 20, Hulse and Calvert teach all limitations of parent claims 1, 8, and 15, Hulse further teaches:
receiving, by the API portal, from a second user device, a third request to access the TCP port ([0022] Each site 110 is a location at which multiple users desire communications services; [0053] the user device attempts to communicate external to the network);
determining, by the API portal, that the second user device cannot authenticate to the API portal; and denying, by the API portal, the second user device access to the TCP port by not requesting the server to add a second IP address of the second user device to a firewall or filter ([0056] If the remote server determines not to authorize the device, embodiments notify the user and/or otherwise indicate that the user device has been denied authorization).
Regarding claim 8, Hulse teaches a device comprising:
memory coupled to processing circuitry, the processing circuitry is configured to ([0040] one or more processors coupled to a system memory):
receive a first request from a user device to connect to a transmission control protocol (TCP) transport layer of a server ([0060] a communication request is received at the on-site router from a user device for communication external to the site-based network);
authenticate the user device based on the first request ([0060] a determination is made as to whether the user device is authorized to communicate as requested over the Internet. This involves the on-site router making a route or forward determination according to whether the user device is listed in its route map as an authorized user device);
provide, to the server, based on the authenticating, a second request to access to a TCP port of the server ([0060] If it is determined that the user device is already authorized to communicate as requested over the Internet (e.g., the user device is included in the on-site router's ACL), the communication can be routed to the destination address associated with the communication request);
receive, from the server, a response to the second request, indicating that the user device is permitted to access the TCP port ([0062] a response is received from the off-site authentication system that includes a captive authentication portal that permits the user device to become authorized to communicate as requested over the Internet. Examiner note: The off-site using cloud-based servers that connect to internet, they are include TCP ports as obviously); and
Hulse does not explicitly teach
send, to the user device, a response to the first request, the response to the first request indicating that the user device is permitted to access the TCP port.
Calvert teaches
send, to the user device, a response to the first request, the response to the first request indicating that the user device is permitted to access the TCP port ([0064] The server may be configured to generate an access determination, based on the authorization information, indicative of whether the user device is authorized to access a secure function of a secure device; [0067] the network device may be configured to receive the access determination from the server via the external network).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention made to include in the Hulse disclosure, an authorization information response from the server, as taught by Calvert. One would be motivated to do so for secure access and access control applications to indicative of whether the user of the mobile device is authorized to access the secure function.
Regarding claim 15, Hulse teaches a system comprising:
an application programming interface (API) portal ([0067] application-programming interface (API), and/or other software development tools or frameworks. Similarly, schematic elements used to represent data or information may be implement);
one or more transmission control protocol (TCP) ports of a server; and memory coupled to processing circuitry, wherein the processing circuitry is configured to ([0040] one or more processors coupled to a system memory):
receive, by the API portal, a first request from a user device to connect to a TCP transport layer of the server ([0060] a communication request is received at the on-site router from a user device for communication external to the site-based network);
authenticate, by the API portal, the user device based on the first request ([0060] a determination is made as to whether the user device is authorized to communicate as requested over the Internet. This involves the on-site router making a route or forward determination according to whether the user device is listed in its route map as an authorized user device);
provide, by the API portal, to the server, based on the authenticating, a second request to access to a TCP port of the server ([0060] If it is determined that the user device is already authorized to communicate as requested over the Internet (e.g., the user device is included in the on-site router's ACL), the communication can be routed to the destination address associated with the communication request);
receive, by the API portal, from the server, a response to the second request, indicating that the user device is permitted to access the TCP port ([0062] a response is received from the off-site authentication system that includes a captive authentication portal that permits the user device to become authorized to communicate as requested over the Internet. Examiner note: The off-site using cloud-based servers that connect to internet, they are include TCP ports as obviously).
Hulse does not explicitly teach
send, by the API portal, to the user device, a response to the first request, the response to the first request indicating that the user device is permitted to access the TCP port.
Calvert teaches
send, by the API portal, to the user device, a response to the first request, the response to the first request indicating that the user device is permitted to access the TCP port ([0064] The server may be configured to generate an access determination, based on the authorization information, indicative of whether the user device is authorized to access a secure function of a secure device; [0067] the network device may be configured to receive the access determination from the server via the external network).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention made to include in the Hulse disclosure, an authorization information response from the server, as taught by Calvert. One would be motivated to do so for secure access and access control applications to indicative of whether the user of the mobile device is authorized to access the secure function.
Claims 5-6, 12-13, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Hulse in view of Calvert and further in view of Salas Lumbreras et al. (US 20250119408 A1), hereafter Salas
Regarding claims 5, 12, and 19, Hulse and Calvert teach all limitations of parent claims 4, 11, and 18, Hulse does not explicitly teach wherein attaching the TCP transport layer daemon to the TCP port is based on adding an Internet Protocol (IP) address of the user device to a firewall or filter in response to the second request.
Salas teaches
attaching the TCP transport layer daemon to the TCP port is based on adding an Internet Protocol (IP) address of the user device to a firewall or filter in response to the second request ([0027] upon successful authentication of the user, retrieving and implementing segmented firewall rules stored in the at least one firewall rules database. Achieving a secure connection of the user device to the private cloud).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention made to include in the Hulse disclosure, the firewalls to filter request devices to access the resources, as taught by Salas. One would be motivated to do so to block traffic that is deemed to be a security threat and allow traffic deemed safe to pass to its intended destination.
Regarding claims 6 and 13, Hulse, Calvert, and Salas teach all limitations of parent claims 5 and 12, Hulse further teaches:
establishing a connection between the user device and the TCP port based on the IP address ([0055] if the communication is to a content host located at a destination IP address on the Internet, the router can pass the communication to a next node of the Internet on the way to the destination IP address).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Motukuru (US 20170118249 A1) and Bonica (US 8364949 B1).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANH NGUYEN whose telephone number is (571)270-0657. The examiner can normally be reached M-F.
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, Umar Cheema can be reached at 5712703037. 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.
/ANH NGUYEN/Primary Examiner, Art Unit 2458
Prosecution Insights