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
Currently pending claims are 1 – 10 & 12 – 21 (claim 11 cancelled).
Response to Arguments
In view of the Remarks filed on 8/10/2015, Applicant's arguments with respect to instant claims have been fully considered and (a) PROSECUTION IS HEREBY REOPENED to provide a new ground of rejection as set forth below for clarity purpose to avoid unnecessary arguments during the prosecution process – please see the following section for the detail of rationale to make the corresponding prior-art(s) rejections and (b) the rejections on Claims 1 & 16 under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph have also been withdrawn.
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.
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 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, 5 – 10, 12, 13 & 20 – 21 are rejected under 35 U.S.C.103 as being unpatentable over in view of Doshi et al. (U.S. Patent 9,514,459), and in view of Sade et al. (U.S. Patent 10,116,658), and in view of Cox et al. (U.S. Patent 2003/0140128).
As per claim 1 & 16, Doshi teaches a non-transitory computer readable medium including instructions that, when executed by at least one processor, cause the at least one processor to perform operations for providing agentless in-memory caching for native network resource connections, the operations comprising:
creating an in-memory cache for one or more actions of a network identity (Doshi: Col. 21 Line 11 – 23 & Col. 1 Line 33 – 44: (a) creating a RAM-based (in-memory) cache, such as an identity cache, to serve the request from users / clients (i.e. network identity) to access network resources, wherein (b) the cache can contain user-attributes and associated data including (e.g.) quality-of-service control, access control and etc., such that an associated identity agent can keep track of the information on an individual user basis for each network access service for improving the perceived quality and performance between the requesting clients and the providing servers);
receiving a request from the network identity to access a network resource (Doshi: see above & Col. 1 Line 33 – 34).
However, Doshi does not disclose expressly authenticating the network identity using a native client and communication protocol.
Sade (& Doshi) teaches authenticating the network identity using a native client and communication protocol (Sade: see above & Col. 3 Line 60 – 67 and Col. 5 Line 20 – 23: (a) a proxy entity of CMS (Credential Management System) authenticates the client (network identity) based on an authentication credential sent in the request via (e.g.) a Kerberos protocol, wherein (b) the CMS entity can be an endpoint device on which the client resides, which constitutes a native client), wherein the native client is configured for communicating transparently with the network resource (Sade: Figure 2B / E-2000: the CMS entity (native client) communicates with an authentication service and operates transparently with the target service (i.e. network resource)).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention was made to propose the modification of authenticating the network identity using a native client and communication protocol because Sade teaches to alternatively, effectively and securely provide a proxy entity of CMS (Credential Management System) authenticates the client (network identity) based on an authentication credential sent in the request via (e.g.) a Kerberos protocol, wherein the CMS entity can be an endpoint device on which the client resides – i.e. as a native client and communication protocol (see above) within the Doshi’s system that creates a RAM-based (in-memory) cache, such as an identity cache, to serve the request from users / clients (i.e. network identity) to access network resources for improving the perceived performance between the requesting clients and the providing servers (see above).
authorizing the network identity based on one or more access policy, the one or more access policy comprising rules for accessibility of the network resource (Sade: see above & Col. 3 Line, Col. 4 Line 45 – 57 and Col. 11 Line 21 – 25: the CMS management entity authorizes the client using the client’s authentication credential to access the target service based on various requirements of the security policy);
identifying an account having a secret, based on the one or more access policy (Sade: see above & Col. 4 Line 51 – 57, Col. 3 Line 18 – 19, Col. 11 Line 18 – 25 and Col. 7 Line 45 – 58 / Line 28 – 35: as per an existing privileged account, obtaining a credential of an access token (i.e. PAT: privileged access ticket) from an authentication service based on a privileged credential (e.g. personal credential) associated with the existing privileged account, wherein the credential of the access token (i.e. PAT) can be a one-time (short-lived) ephemeral credential(s)) || (Doshi: see above);
accessing the network resource using the secret (Sade: see above & Col. 4 Line 55 – 57, Col. 3 Line 18 – 19, Col. 2 Line 29 – 32 and Col. 7 Line 28 – 35: accessing the target service using the created (e.g.) one-time access token (i.e. PAT) based on the privileged credential (e.g. personal credential) associated with the existing privileged account to establish a communication session with the target service) || (Doshi: see above).
However, though Doshi teaches before using the in-memory cache, the system first checks (validates) the user attributes associated with the current user authentication request should be maintained either only for a duration of the current session or should be maintained across (between) multiple sessions so as to determine whether an in-memory cache (i.e. a non-persistent cache) or a persistent disk storage should be used respectively (Doshi (Col. 21 Line 17 – 24 / Line 52 – 58 & Col. 1 Line 33 – 44), Doshi does not disclose expressly (a) based on caching policies defining how and whether in-memory cache may be used to perform an action and also (b) including a validation of comparing metadata stored in the in-memory cache to metadata associated with the request.
PE2E Search
PNG
media_image1.png
102
644
media_image1.png
Greyscale
Cox (& Doshi) teaches based on caching policies defining how and whether in-memory cache may be used to perform an action, performing, prior to performing one or more action using the in-memory cache, at least one of:
(a) Cox teaches a network entity (a user device) sends a request to a security service system using an SSL session connection to access system resources and the sender (requester) is required to attach a digital certificate (i.e. metadata) to the incoming request for validation (prior-to) before it is allowed to proceed to its destination system so as to prevent unauthorized intrusions (Cox: Col. 26 Line 43 – 47 / Line 64 – 67 / Line 59 – 62 & Col. 27 Line 1 – 5); and
(b) Cox further teaches, according to a validation process, a caching policy specifies an associated authorization module is required to strip (extract) the digital certificate (i.e. metadata) from the incoming request and then compare it (first) to an in-memory cache to determine whether the request can be validated to grant the access request and in case if there is no match from the in-memory cache, then a query is then made to a data store to determine if the request is valid (Cox: Col. 27 Line 1 – 10).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention was made to propose the modification of, based on caching policies, defining how and whether in-memory cache may be used to perform an action, performing, prior to performing one or more action using the in-memory cache because Cox teaches to alternatively, effectively and securely provide an enhanced security mechanism, wherein a network entity (a user device) sends a request to a security service system using an SSL session connection to access system resources and the sender (requester) is required to attach a digital certificate (i.e. metadata) to the incoming request for validation (prior-to) before it is allowed to proceed to its destination system so as to prevent unauthorized intrusions (see above) within the Doshi’s system that creates a RAM-based (in-memory) cache, such as an identity cache, to serve the request from users / clients (i.e. network identity) to access network resources for improving the perceived performance between the requesting clients and the providing servers (see above).
a first validation to validate whether the in-memory cache can be used to perform the one or more action, wherein the first validation includes comparing metadata stored in the in-memory cache to metadata associated with the request (Cox: Col. 27 Line 1 – 10: according to a validation process, a caching policy specifies an associated authorization module is required to strip (extract) the digital certificate (i.e. metadata) from the incoming request and then compare it (first) to an in-memory cache to determine whether the request can be validated to grant the access request and in case if there is no match from the in-memory cache, then a query is then made to a data store to determine if the request is valid); or a second validation to validate how the in-memory cache can be used to perform the one or more action (Doshi & Cox: see above).
determining, based on at least one of the first validation or the second validation (Doshi || Cox: see above),
whether to perform the one or more action using the in-memory cache in addition to or instead of the network resource (Doshi: see above) || (Cox: see above: for improving the perceived performance); and
based on the determination, performing the one or more action using the in- memory cache in addition to or instead of the network resource (Doshi: see above ||
Cox: see above) – this is also consistent with the disclosure of the instant specification (SPEC-PG.PUB: Para [0192]: the action is performed on in-memory cache instead of on network resource based on the determination whether data required for performing the requested action is available in in-memory cache and if so, the action may be performed using the data in in-memory cache while if the data is not available, the action may be performed using network resource).
As per claim 5, Doshi as modified teaches wherein the in-memory cache is created based on a relationship of each of the plurality of network identities to the network resource (Doshi || Cox: see above).
As per claim 6, Doshi as modified teaches wherein accessing the network resource using the secret comprises accessing the network resource through a just-in-time session (Sade: see above & Col. 4 Line 55 – 57, Col. 3 Line 18 – 19, Col. 2 Line 29 – 32 and Col. 7 Line 28 – 35: (a) the client can use the received access token (i.e. PAT) to establish a communication session for accessing the target service and (b) the credential(s) of the access token can also be a type of one-time credential(s) based on the time of the request parameter, which is a one-time use (i.e. for a just-in-time service session) to access target services for authentication and would be invalidated on the next connection time of access service for reducing the risk to be compromised from malicious attacks (Sade: Col. 7 Line 28 – 35 & Col. 2 Line 30 – 32)) || (Doshi || Cox: see above).
As per claim 7 – 8, 12, 15 & 20 – 21, Doshi as modified teaches wherein creating the in- memory cache for the one or more actions of a network identity is based on metadata of the network identity (Doshi: see above & Col. 21 Line 11 – 23 & Col. 1 Line 33 – 44: (a) creating a RAM-based (in-memory) cache, such as an identity cache, to serve the request from users / clients (i.e. network identity) to access network resources, wherein (b) the cache can contain user-attributes and associated data) || (Cox: see above).
As per claim 9, Doshi as modified teaches wherein performing one or more action using the in-memory cache is based on metadata of the network identity (Doshi: see above & Col. 21 Line 11 – 23 & Col. 1 Line 33 – 44: the cache from the identity cache of the proxy can contain user-attributes and associated data including (e.g.) quality-of-service control, access control and etc., such that an associated identity agent can keep track of the information on an individual user basis for each network access service for improving the perceived quality and performance between the requesting clients and the providing servers – as such, it is evidently the use of cache data is also based on metadata of the network resource w.r.t. the quality-of-service control, access control, and etc.) || (Cox: see above).
As per claim 10, Doshi as modified teaches wherein performing one or more action using the in-memory cache is based on the type of the one or more actions (Doshi: see above & Col. 21 Line 50 – 58: using the in-memory cache or using persistent disk storage cache of an identity cache can be determined based on whether the attribute / data is used by a type of action between two different sessions) || (Cox: see above).
As per claim 13, Doshi as modified teaches creating one or more layers of the in-memory cache (Doshi: see above & Col. 21 Line 11 – 23 & Col. 1 Line 33 – 44: (a) creating a RAM-based (in-memory) cache storage location to serve the request from users / clients (i.e. network identity) for accessing network resources constitutes one type of specific access-layer of cached memories) || (Cox: see above).
Claims 2 – 4, 14 & 17 – 19 are rejected under 35 U.S.C.103 as being unpatentable over in view of Doshi et al. (U.S. Patent 9,514,459), and in view of Sade et al. (U.S. Patent 10,116,658), in view of Cox et al. (U.S. Patent 2003/0140128), and in view of Schaefer et al. (U.S. Patent 8,099,758).
As per claim 2 & 17, Doshi as modified teaches determining there is no hit on the in-memory cache; and accessing a regional content delivery network (CDN) of caching (Doshi || Cox: see above) || (Schaefer: see above & Col. 18 Line 9 – 11 / 15 – 16: the content to be cached can be found in two different available locations – a local copy cache and a remote (cached) file system and as such, if the target is not available on the in-memory cache, it can be accessed from the remote (cached) file system).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention was made to propose the modification of creating at least one new entity associated with the original network resource because Schaefer teaches to alternatively, effectively and securely utilize an access policy to manage the data content of a file system portion, wherein the content to be cached can be found in two different available locations – a local copy cache and a remote (cached) file system (see above) within the Doshi’s that creates a RAM-based (in-memory) cache, such as an identity cache, to serve the request from users / clients (i.e. network identity) to access network resources for improving the perceived performance between the requesting clients and the providing servers (see above).
As per claim 3 & 18, Doshi as modified teaches wherein the one or more requested action is routed to a closest caching region with fitting CDN policies (Schaefer: see above) || (Doshi: see above & Col. 1 Line 37 – 44: the proxy cache can re-direct (re-route) the data access request based on frugal (economic cost-saving) use of physical paths (I.e. shortest / closest paths) by enforcing access control policies at boundaries between organizations).
As per claim 4 & 19, Doshi as modified teaches determining that there are no hits in both the in-memory cache and the regional CDN; accessing the network resource (Schaefer: see above & Col. 18 Line 9 – 11 / 15 – 16 & Col. 10 Line 17 – 20: when the target content is available on neither of two different (cached) locations – i.e. a local copy cache and a remote (cached) file system – accordingly, the only resolution must be to access from its providing server to retrieve the original target network resource and subsequently, the accessed result content can be cached for later use on the same (local) host PC and meantime, writing back into a central repository for sharing and backup purpose (Doshi || Cox: see above) || (Schaefer: see above & Col. 10 Line 17 – 20)).
As per claim 14, Doshi as modified teaches synchronizing the in-memory cache with data stored in the network resource (Schaefer: see above & Col. 18 Line 9 – 11 / 15 – 16 & Col. 10 Line 17 – 20: when the target content is available on neither of two different (cached) locations – i.e. a local copy cache and a remote (cached) file system – accordingly, the only resolution must be to access from its providing server to retrieve the original target network resource and subsequently, the accessed result content can be cached for later use on the same (local) host PC and meantime, writing back into a central repository for sharing and backup purpose – i.e. synchronizing the in-memory cache with data stored in the network
resource (Schaefer: see above & Col. 10 Line 17 – 20)) || (Doshi || Cox: see above).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LONGBIT CHAI whose telephone number is (571)272-3788. The examiner can normally be reached Monday - Friday 9: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, Lynn D. Feild can be reached at 571-272-2092. 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.
---------------------------------------------------
/Longbit Chai/
Longbit Chai E.E. Ph.D.
Primary Examiner, Art Unit 2431
No. #2499 – 2026 ---------------------------------------------------
Prosecution Insights