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 .
Claim Status
Claims 1-20 are under examination.
Priority
Applicant’s claim to priority to the following provisional application has been acknowledged by the examiner: 63/545,262 (10/23/2023).
Information Disclosure Statement
The information disclosure statement filed 12/04/2024 fails to comply with 37 CFR 1.98(a)(2), which requires a legible copy of each cited foreign patent document; each non-patent literature publication or that portion which caused it to be listed; and all other information or that portion which caused it to be listed. It has been placed in the application file and the references that have not been considered have been struck through.
Claim Objections
Claim 7 is objected to because of the following informalities: “The system of claim 1. wherein” should read “The system of claim 1, wherein”. Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claims 2, 9, and 16 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as failing to set forth the subject matter which the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the applicant regards as the invention.
Regarding claims 2, 9, and 16, they recite the limitations “authenticating the user” and “authorizing the user”. There is double antecedent basis for these limitations as it is unclear whether they refer to “authenticate, by an identity provider on the cloud platform, the user” and “authorize, by a usage service on the cloud platform, the user” or “authenticate by an identity manager on the system, the user” and “authorize, by a usage service on the system, the user”. For examination purposes, “authenticating the user” and “authorizing the user” are being interpreted as referring to “authenticate by an identity manager on the system, the user” and “authorize, by a usage service on the system, the user”.
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.
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.
Claims 1-3, 7-10, 14-17, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Chauhan (US Patent Publication No. 2022/0292180 – Provided by Applicant) in view of Srinivasan et al. (US Patent No. 9,069,979), hereinafter Srinivasan.
Regarding claim 1, Chauhan teaches
A system for enabling authentication by a local identity provider when cloud-based authentication is unavailable (Chauhan ¶195: “the systems and methods discussed herein provide for storing, accessing, and synchronizing data from a SaaS application, enabling SaaS data to be interacted with, regardless of connectivity, while providing secure authentication when offline.”), the system comprising:
one or more processors (Chauhan Fig. 1);
and a non-transitory computer readable medium storing a plurality of instructions, which when executed, cause the one or more processors to (Chauhan ¶196: “the systems and methods described above may be implemented as a method, apparatus or article of manufacture using programming and/or engineering techniques to produce software, firmware, hardware, or any combination thereof.”):
determine whether a system, which is local for a user, is connected to a cloud platform, in response to receiving a request to authenticate the user (Chauhan ¶158: “the user inputs their credentials into the client application 1106 running on the client device 1100. In step 1202, the client application determines whether the client application 1106 has connectivity to the application server.”);
authenticate, by an identity provider on the cloud platform (Chauhan ¶61: “Client agent 304 and application management framework of this architecture act to provide policy driven management capabilities and features such as connectivity and SSO (single sign on) to enterprise resources/services 308.”), the user based on identifying a cloud identity assigned to the user, [from a plurality of cloud identities associated with subscriptions] to access an application (Chauhan ¶159: “At step 1206, the network application 1102 evaluates whether the credentials received match stored credentials in the one or more servers 1104 or communicates with an authentication server to determine if the credentials indicate the user is authorized (e.g. by matching authorized credentials in a user database).”), in response to a determination that the system is connected to the cloud platform (Chauhan ¶158: “In step 1204, if there is a functioning communication channel 1118, and the client application 1106 is online, the embedded browser 1108 sends the credentials to the network application 1102.”);
authorize, by a usage service on the cloud platform (Chauhan ¶55: “Application controller services 274 may include management services, provisioning services, deployment services, assignment services, revocation services, wrapping services, and the like.”), the user, authenticated by the identity provider (Chauhan ¶160: “In step 1210, if the credentials do match the stored credentials, the one or more servers 1104 or an authentication server may transmit an authentication token to the client application 1106, authorizing the client device 1100.”), to access the application [based on one of the subscriptions associated with the cloud identity] assigned to the user (Chauhan ¶163: “the token validity time would allow access to data in the network application 1102 for a certain period of time until the token expires.”);
[match a system user identity with the cloud identity, which were assigned to the user;]
authenticate, by an identity manager on the system (Chauhan ¶156: “As a component of the client application 1106, the embedded browser 1108 further has the ability to authenticate the client application 1106 via an authenticator 1110 (sometimes referred to as an authentication client 1110)”), the user based on identifying a system identity which is assigned to the user, [from multiple system identities matched with multiple cloud identities] (Chauhan ¶174: “In step 1226, the client application 1106 evaluates whether the intercepted authentication credentials match the stored credentials in the memory of the client device 1100, from step 1212, similar to the process in step 1206.”), in response to a determination that the system is not connected to the cloud platform (Chauhan ¶173: “When offline, the client application 1106 may intercept the attempted transmission of the authentication credentials because it has determined that the client device 1100 is offline.”);
and authorize, by a usage service on the system (Chauhan ¶61: “The client agent 304 obtains policies from gateway server 306 to control the behavior of the managed applications 310 on the client device 302.”), the user, authenticated by the identity manager, to access the application (Chauhan ¶175-176: “In step 1228, if the intercepted credentials match the credentials stored in the client device 1100, the client application proceeds to retrieve the stored authentication token, from step 1216, from the memory of the client device 1100 … In step 1230, the data that was cached in the memory of the client device 1100, from step 1220, is accessed by the embedded browser 1108 using the retrieved authentication token.”) Chauhan fails to explicitly teach
from a plurality of cloud identities associated with subscriptions,
based on one of the subscriptions associated with the cloud identity,
match a system user identity with the cloud identity, which were assigned to the user,
from multiple system identities matched with multiple cloud identities,
and based on one of multiple subscriptions associated with one of the multiple cloud identities matched with the system identity assigned to the user.
However, Srinivasan teaches authenticate, [by an identity provider on a cloud platform], from a plurality of cloud identities associated with subscriptions (Srinivasan col. 4 lines 44-47: “As is discussed above, various customers can establish separate identity domains within the IDM system. Typically, these customers pay some subscription fee in order to establish such identity domains.”)
to access the application based on one of the subscriptions associated with the cloud identity assigned to the user (Srinivasan col. 5 lines 4-16: “each identity domain of a customer who subscribes to PaaS or SaaS hosted in the cloud computing environment is associated with a unique identity domain identifier. Such an identity domain identifier can be unique within the cloud computing environment … access control policies that are used to protect resources that belong to an identity domain are also associated with the identity domain identifier for that identity domain.”)
match a system user identity with the cloud identity, which were assigned to the user (Srinivasan col. 11 lines 6-9: “AppleCore can make use of a mapping table that contains mappings between user identifiers and enterprise identifiers/customers. Such mappings alternatively can be represented within an LDAP directory.”);
authenticate, [by an identity manager on the system], the user based on identifying a system identity which is assigned to the user, from multiple system identities matched with multiple cloud identities (Srinivasan col. 15 lines 40-49: “a particular user is always associated with the same multi-tenant unique identifier once his user account has been created, and that same multi-tenant unique identifier is used by the cloud environment's authentication system to authenticate the user every time that the user seeks access to a service within the environment. Because the multi-tenant unique identifier specifies the identity domain to which a user belongs, the LDAP server is able to determine which of the LDAP directory's subtrees are applicable to the user.”)
to access the application based on one of multiple subscriptions associated with one of the multiple cloud identities matched with the system identity assigned to the user (Srinivasan col. 5 lines 4-16: “each identity domain of a customer who subscribes to PaaS or SaaS hosted in the cloud computing environment is associated with a unique identity domain identifier. Such an identity domain identifier can be unique within the cloud computing environment … access control policies that are used to protect resources that belong to an identity domain are also associated with the identity domain identifier for that identity domain.”).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to modify Chauhan in view of Srinivasan in order to increase efficiency by reducing the number of identity management needed for multiple users with subscriptions from multiple cloud entities (Srinivasan col. 2 lines 37-42: “The IDM System can be shared among multiple independent and separate ‘tenants.’ or IDM system customers, so that the IDM system is more densely utilized. Thus, there is no need for a separate IDM system to be instantiated for each separate customer.”).
Claims 8 and 15 are substantially similar to claim 1 and are rejected under the same rationale.
Regarding claim 2, Chauhan and Srinivasan teach the system of claim 1, Chauhan further teaches wherein authenticating the user further comprises providing an access token to the application (Chauhan ¶175: “In step 1228, if the intercepted credentials match the credentials stored in the client device 1100, the client application proceeds to retrieve the stored authentication token, from step 1216, from the memory of the client device 1100.”), and authorizing the user to access the application is further based on the application providing the access token (Chauhan ¶176: “In step 1230, the data that was cached in the memory of the client device 1100, from step 1220, is accessed by the embedded browser 1108 using the retrieved authentication token.”).
Claims 9 and 16 are substantially similar to claim 2 and are rejected under the same rationale.
Regarding claim 3, Chauhan and Srinivasan teach the system of claim 1, but Chauhan fails to teach wherein each subscription is based on the user having at least one of an individual account or a group account subscribed to a product agreement.
However, Srinivasan teaches wherein each subscription is based on the user having at least one of an individual account or a group account subscribed to a product agreement (Srinivasan col. 4 lines 44-47: “As is discussed above, various customers can establish separate identity domains within the IDM system. Typically, these customers pay some Subscription fee in order to establish such identity domains.”).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to modify Chauhan in view of Srinivasan in order to increase efficiency by only needing one identity management system for multiple users with subscriptions from multiple cloud entities (Srinivasan col. 2 lines 37-42: “The IDM System can be shared among multiple independent and separate ‘tenants.’ or IDM system customers, so that the IDM system is more densely utilized. Thus, there is no need for a separate IDM system to be instantiated for each separate customer.”).
Claims 10 and 17 are substantially similar to claim 3 and are rejected under the same rationale.
Regarding claim 7, Chauhan and Srinivasan teach the system of claim 1. Chauhan further teaches wherein the plurality of instructions further causes the processor to:
cache each event initiated by the user (Chauhan ¶187: “In step 1312, the client application 1106 stores, logs, or records, each intercepted user interaction in the memory of the client device 1100. The interactions can be stored in the same memory that the cached data is stored in, from step 1302, or the interactions can be stored in different memory.”), who was authorized by the usage service on the system, until the system is re-connected to the cloud platform (Chauhan ¶188: “The stored user interactions are buffered until the client application 1106 determines that the client application 1106 is online and connected to the network application 1102 again.”), and
store each cached event to the cloud platform (Chauhan ¶189: “In step 1316 the client application determines that there is communication with the one or more servers 1104 and sends the buffered user interactions to the one or more servers 1104.”).
Claims 14 and 20 are substantially similar to claim 7 and are rejected under the same rationale.
Claims 4-5, 11-12, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Chauhan in view of Srinivasan in view of Voice et al. (US Patent Publication No. 2016/0191520), hereinafter voice.
Regarding claim 4, Chauhan and Srinivasan teach the system of claim 1, but fail to teach wherein the identity manager authenticating the user is further based on having received prior consent from an administrative user for the user to be authenticated by the identity manager.
However, Voice teaches wherein the identity manager authenticating the user is further based on having received prior consent from an administrative user for the user to be authenticated by the identity manager (Voice ¶164: “The sender unit 2920 may include a Graphic User Interface (GUI) that allows the administrator of the sender unit 2920 to determine a desired offline authentication security scheme on a per user or group basis. For example, the GUI may include pull down menus to allow the administrator of the sender unit 2920 to select one of a number of offline authentication security schemes to send to the recipient unit 2915 in response to a request from the recipient unit 2915.”).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to modify Chauhan and Srinivasan in order to allow an administrator to control whether certain users are allowed to have access when they are offline (Voice ¶21: “When the recipient unit is off-line, i.e., not communicating with the target source, the system administrator may wish to also provide authentication of the user for accessing the resources of the recipient unit ... However, the administrator may wish to limit the use of the laptop by the user when the user is off-line.”).
Claims 11 is substantially similar to claim 4 and is rejected under the same rationale.
Regarding claim 5, Chauhan, Srinivasan, and Voice teach the system of claim 4, Chauhan further teaches wherein the identity manager authenticating the user is additionally based on the identity manager authenticating the user within an allowed time (Chauhan ¶174: “Access to data may be granted upon verification of an authentication token, an un-expired token validity time, and/or other methods or combinations of methods that verify whether a device is approved to access data.”).
Claim 12 is substantially similar to claim 5 and is rejected under the same rationale.
Claim 18 is substantially similar to claims 4 and 5 and is rejected under the same rationale
Claims 6, 13, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Chauhan in view of Srinivasan in view of Anand et al. (US Patent Publication No. 2016/0323270), hereinafter Anand, in view of Hernandez Serrano et al. (US Patent Publication No. 2023/0144505), hereinafter Hernandez.
Regarding claim 6, Chauhan and Srinivasan teach the system of claim 1, but fail to teach wherein the plurality of instructions further causes the processor to display, via a graphical user interface associated with the application, an offline mode, a date and time when an administrative user consent expires for authentication by the identity provider,
However, Anand teaches wherein the plurality of instructions further causes the processor to display, via a graphical user interface associated with the application, an offline mode (Anand ¶21: “As shown in the operational flow of process 200, a user login prompt for an application is displayed on a display system of computing system 101, wherein the user login prompt provides an offline access option for a user to request offline access to the application for a period of time (201).”), a date and time (Anand ¶22: “Additionally or alternatively, the offline access option could comprise one or more time periods for selection by the user.” ) when an administrative user consent expires for authentication by the identity provider (Anand ¶23: “users could have different offline access permissions or licensing terms that dictate which time periods are authorized for each user, and authentication server 130 could populate these time periods for the user based on the user login credentials.”)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to modify Chauhan and Srinivasan to only allow a user offline access if authorized to increase access flexibility for users (Anand ¶26: “the user can still utilize the application in areas with no network connectivity during the authorized time period. This technique allows for contract-based time periods of authorized use, which may be enforced in the application for subscriptions and other restricted usage.”).
Chauhan, Srinivasan, and Anand fail to teach and the system identifier assigned to the user, in addition to the cloud identifier assigned to the user.
However, Hernandez teaches and the system identifier assigned to the user, in addition to the cloud identifier assigned to the user (Fig. 16A - element 1605).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to modify Chauhan, Srinivasan, and Anand to include these identifiers to create a more familiar user experience (Hernandez ¶269: “This is done so that a visual presentation of the first graphical user interface is similar to a visual presentation of the native graphical user interface associated with the external cloud environment. As such, a familiarity of usage (of the GUI) is offered to users of the external cloud environment.”).
Claims 13 and 19 are substantially similar to claim 6 and are rejected under the same rationale.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALEC ANKRUM whose telephone number is (571)272-9209. The examiner can normally be reached M-F 7:15am-3:15pm.
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, Ali Shayanfar can be reached at 571-270-1050. 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.
/A.C.A./Examiner, Art Unit 2434
/NOURA ZOUBAIR/Primary Examiner, Art Unit 2434
Prosecution Insights