DETAILED ACTION
This communication responsive to the Application No. 18/935,901 filed on 05/07/2026. Claims 1-20 are pending and are directed towards enforcing a user-specific authorization policy for authorizing an interaction between applications running on a same computing device
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 .
Response to arguments
Rejection of claims 1-5, 7, 9-15, and 17-20 under 35 U.S.C. 103
Applicants’ arguments with respect to claims 1-5, 7, 9-15, and 17-20 are fully considered and are not persuasive.
Applicants’ argument regarding User-specific authorization policy: Applicant argues that Tan’s white-listing in para [0049] is application specific rather than user-specific and that Tan lacks any list of users. Examiner disagrees. This argument is solely based on Tan alone and ignores Omnes’ contribution. Omnes, para [0005] discloses identifying a terminal jointly with a user so that only members of a household i.e., specific individuals from an identifiable group can access declared content from declared terminals. When Tan’s application to application whitelisting (which establishes which interactions are permitted between apps) is combined with Omnes’ user specific access rights policy (which describes who may exercise that access), the combination teaches a policy that varies both by application pairing and by user identity i.e., a user specific authorization policy for each user from an authorized list. Tan’s policy decisions regarding whether a first application and a second application are permitted to interact would be modified to also determine, based on the user token received from the second application, whether the first user is authorized to perform the interaction. The combined policy would therefore evaluate both the particular application pairing and the identity and access rights of the user. This proposed combination teaches, verifying that the applications are authorized to interact and the first user is authorized, based on the user token received from the second application.
Additionally, Tan, para [0019] describes detecting which applications can interact with the mobile client application access the server. A mobile client application accessing a server inherently does so within a user session (e.g., an authenticated account), so the compatible application determination shows that Tan is aware of user identity. It operates in the context of a specific user’s active session. Hence, this argument is not persuasive.
Applicants’ argument regarding intent authorization request including token and intent information: Applicant argues that Tan’s auth token is used solely for a cryptographic handshake obtaining a session key and is unrelated to identifying an intent and that this differs from Tan’s custom intent object. Examiner disagrees. This argument treats two disclosures in isolation rather than as they function together in Tan’s overall system. Tan describes a custom intent that identifies a receiving application and the action to be performed, and separately describes a token-based mechanism (para [0065]) used to establish an authorized communication session with the host server before that interaction is permitted to proceed. Tan discloses custom intent messaging (identifying the intent) and token-based session establishment (authenticating the request to the server) and a request that carries both an identifying token and intent information, which is consistent with how the mechanism in Tan would operate to authorize an inter-application interaction via a server. Moreover, applicant’s assertion that Tan’s token facilitates session encryption only and thus cannot also serve an authorization or gatekeeping function, is not taught by Tan. However, a token used to establish a session with a host server for the purpose of enabling further application interaction is reasonably understood, under BRI, to also serve as an identifier verifying the requesting entity is permitted to proceed i.e., an authorization function even if data encryption is an additional purpose.
Applicants’ argument regarding validating user authorization for both applications: Applicant argues that Omnes, para [0074] and [0026] validate a network access context i.e., subscription to a network service, not user authorization to access two applications on the same device. Examiner disagrees. Omnes describes identifying a terminal jointly with a user specifically to ensure that only authorized individuals (household members) access content via declared, registered terminals. This is a user-identity based validation, not merely a network context check and the network access context in [0074] is the mechanism by which the system confirms that this particular user, on this particular declared terminal, holds valid rights, which is user-specific validation rather than a generic network level check. Regarding the “both applications” limitation, Tan already discloses two applications interacting on the same device (e.g., the document editor and collaboration platform example in [0049]. Omnes is relied upon to supply the validation of user rights mechanism, which when applied within Tan’s two application on one device framework teaches verifying that the same authorized user has rights extending to both applications. Hence, applicants’ argument that Omnes does not disclose the “both applications” language is not persuasive as the structural element of two apps in one device is supplied by Tan.
Rejection of claims 6, 8, and 16 under 35 U.S.C. 103
Dependent claims 6,8 and 16 are also rejected for the same reasons as described above.
Suggested amendments: To overcome the prior art of record, examiner suggests to amend the validating step to recite that the first application’s acceptance of the intent is conditioned on, and occurs only after, the server’s validation response emphasizing a gatekeeping step before any inter-app data exchange, distinguishing Tan’s session key-exchange, which secures a channel after the target app is already identified and Omnes’ subscription check.
Additionally, amendment could recite that the policy is provisioned individually for each user identifier in a stored list of user identifiers associated with the first application, to overcome Tan’s device whitelist which does not have per-user list structure. Recite that validation confirms the first user’s authorization to access the first and second application using the same user identifier or session, so the check cannot be met by Omnes’ terminal-based household validation, which is not tied to a single user credential across two applications.
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-5, 7,9-15, 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Tan et al. (US 20140068779 A1), hereinafter referred to as Tan, in view of Omnes et al. (US 20150172283 A1), hereinafter referred to as Omnes.
As per claim 1, Tan discloses a method for enforcing a user-specific authorization policy for authorizing an interaction between applications running on a same computing device, the method comprising:
provisioning, at an intent management server, a user-specific authorization policy for each respective user from a list of users authorized to access a first application running on a computing device, the user-specific authorization policy identifying one or more allowed intents that the first application is authorized on behalf of the respective user to accept from a second application running on the computing device; (The secure inter-application communication system secures the inter-application communication by issuing the Intent in two phases. First, an Intent to detect which applications are capable of interacting with the mobile client application accessing the server, Tan, para [0019]. The white-listed applications include those applications between which inter-application communication is allowed or authorized, Tan, para [0049], Fig 6 depicts example of components of mobile applications, including a sending application and a receiving application, in a mobile device. Additionally, para [0005] of Omnes discloses identifying a terminal jointly with a user so that only members of a household i.e., specific individuals from an identifiable group can access declared content from declared terminal).
receiving, at the intent management server, an intent authorization request from the second application intending to interact with the first application on behalf of a first user from the list of users, the intent authorization request from the second application including an user token associated with the first user and information identifying at least one intent that the second application is intending to invoke with the first application; (When Application 1 issues an Intent using the default Intent system, all applications 1-N, including the malicious and unauthorized applications, can detect the Intent, and have access to data being passed. However, when Application 1 issues a custom Intent 415, only the white-listed applications 410 can detect the custom Intent 415 and know how to respond to it. The unauthorized or malicious applications 420, on the other hand, would not know how to respond to the custom Intent, and would thus ignore the custom Intent, Tan, para [0051]. The auth token may be obtained from the host server or an authentication server. The encryption/decryption module 635 can start a background service that establishes a communication session with the host server 100 (or an authentication server) to obtain a newly generated key, Tan, para [0065]. The intent authorization request is analogous to the custom intent requesting actions and the systems use of auth token obtained from a host/auth server as an input to secure the transaction).
providing, at the intent management server, a response to the intent authorization request based on the user-specific authorization policy provisioned for the first user from the list of users, the response indicating whether the second application running on the computing device is authorized on behalf of the first user to invoke the at least one intent with the first application running on the computing device (When application 1 issues a custom Intent 415, only the white-listed applications 410 can detect the custom Intent 415 and know how to respond to it. Once a receiving application is identified or selected, a secure channel can be opened only the application which is chosen can receive the data, Tan, para [0051]- [0052]. The response indicating whether authorized is analogous to the system behavior where only whitelisted/selected applications can respond/participate in custom-intent exchange. Authorization is enforced by the system’s selection/whitelisting mechanics is equivalent to returning/producing an authorization decision for a requested intent/action).
However, Tan does not explicitly disclose the limitation:
validating, at the intent management server, the user token received from the second application by verifying that the first user is authorized to access both the first and second applications running on the computing device; and
Omnes discloses:
validating, at the intent management server, the user token received from the second application by verifying that the first user is authorized to access both the first and second applications running on the computing device; and (The method comprises checking the validity of the authentication token by a server entity before granting access. The authentication token is associated with a user and with access rights granted to that user. Access to a service or application is granted only if the access rights associated with the user are valid. The authentication token is generated on the basis of a unique identifier of the terminal and the network access context of the terminal, Omnes, para [0026], [0074]. Here, the server-side validation of a user token by checking whether the user’s access rights authorize access to the relevant application/services on the same device)
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Tan with Omnes by creating secure channel for inter-application communication using intents (Tan) with authentication by token (Omnes). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Tan with Omnes in order to ensure information is securely exchanged between entities and create a single authorization policy that varies by both application pairing and user identity i.e., a user specific authorization policy for each user from an authorized list (See Omnes, para [0026])
As per claim 2, Tan and Omnes disclose the method of claim 1, wherein providing the response comprises:
Furthermore, Omnes discloses:
determining, after validating the user token, from the user-specific authorization policy provisioned for the first user, whether the at least one intent is included in the one or more allowed intents that the first application is authorized to accept from the second application running on the computing device; and (Checking the validity of the service access rights, comprising at least checking an access right associated with the network access context of the terminal, Omnes, para [0006]. Here, it is determined whether the terminal has valid rights to access the requested service and bases decisions on those rights. This is analogous to determining whether a requested intent/action is permitted under a user-specific policy).
when it is determined that the at least one intent is not included in the one or more allowed intents that the first application is authorized to accept from the second application running on the computing device, including a message in the response to indicate that the second application running on the computing device is not authorized on behalf of the first user to invoke the at least one intent with the first application running on the computing device (When a token is invalid or access rights are not valid, access is not granted. Also, a response message is transmitted, indicating the result, Omnes, para [0049]. If rights are not valid, access is denied, and in the token revocation and validity check flows, the server returns a response indicating whether the token is valid or not).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Tan with Omnes by creating secure channel for inter-application communication using intents (Tan) with authentication by token (Omnes). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Tan with Omnes in order to ensure information is securely exchanged between entities and create a single authorization policy that varies by both application pairing and user identity i.e., a user specific authorization policy for each user from an authorized list (See Omnes, para [0026])
As per claim 3, Tan and Omnes discloses the method of claim 1, wherein providing the response comprises:
determining, after validating the user token, from the user-specific authorization policy provisioned for the first user, whether the at least one intent is included in the one or more allowed intents that the first application is authorized to accept from the second application running on the computing device; and (The white-listed applications include those applications between which inter-application communication is allowed or authorized, Tan, para [0049]).
Furthermore, Omnes discloses:
when it is determined that the at least one intent is included in the one or more allowed intents that the first application is authorized to accept from the second application running on the computing device, issuing, at the intent management server, an intent authorization token with the response to indicate that the second application running on the computing device is authorized on behalf of the first user to invoke the at least one intent with the first application running on the computing device (Generating a valid authentication token on the basis of the unique identifier of the terminal and the network access context, and transmitting the token to the terminal, Omnes, para [0006]. When access rights are valid, the system generates and transmits a token authorizing access. This token is directly used to permit access going forward).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Tan with Omnes by creating secure channel for inter-application communication using intents (Tan) with authentication by token (Omnes). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Tan with Omnes in order to ensure information is securely exchanged between entities and create a single authorization policy that varies by both application pairing and user identity i.e., a user specific authorization policy for each user from an authorized list (See Omnes, para [0026])
As per claim 4, Tan and Omnes discloses the method of claim 3, wherein the user-specific authorization policy further defines an expiration time after which the user-specific authorization policy provisioned for each respective user is no longer valid, the method further comprising:
Furthermore, Omnes discloses:
determining, at the intent management server, that the expiration time has not expired before issuing the intent authorization token (Token generation date may be stored during the token validity check if the expiry date is exceeded the token can be revoked, Omnes, para [0063]. This teaches that token validity depends on expiration and that server checking of expiration occurs before use/issuance).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Tan with Omnes by creating secure channel for inter-application communication using intents (Tan) with authentication by token (Omnes). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Tan with Omnes in order to ensure information is securely exchanged between entities and create a single authorization policy that varies by both application pairing and user identity i.e., a user specific authorization policy for each user from an authorized list (See Omnes, para [0026])
As per claim 5, Tan and Omnes discloses the method of claim 3, wherein the user-specific authorization policy further identifies one or more particular computing devices for which the user-specific authorization policy is valid, the method further comprising:
Furthermore, Omnes discloses:
retrieving, at the intent management server, from the intent authorization request, a device identifier associated with the computing device running the first and the second applications; and (Authentication by token for accessing a service from a terminal on receipt of a service access authorization request. The generated authentication token is based on a unique identifier of the terminal, Omnes, para [0008]- [0011]. The unique identifier of the terminal functions as the device identifier. It is used in token generation logic).
determining, at the intent management server, that the device identifier is associated with the one or more particular computing devices identified in the user-specific authorization policy before issuing the intent authorization token (Check that the terminal is authorized under the user’s access rights and network context before generating a token, Omnes, para [0076]. Device context, which is terminal identifier and access context, is checked before token generation which binds token issuance to authorized devices).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Tan with Omnes by creating secure channel for inter-application communication using intents (Tan) with authentication by token (Omnes). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Tan with Omnes in order to ensure information is securely exchanged between entities and create a single authorization policy that varies by both application pairing and user identity i.e., a user specific authorization policy for each user from an authorized list (See Omnes, para [0026])
As per claim 7, Tan and Omnes discloses the method of claim 3, further comprising:
Furthermore, Tan discloses:
binding the intent authorization token at the first application to enable the interaction between the first and second applications (Once a receiving application is identified or selected, a secure channel can be opened, only the application which is chosen can receive the data, Tan, para [0061]. The secure channel functions as a binding mechanism)
As per claim 9, Tan and Omnes disclose the method of claim 8, further comprising:
Furthermore, Tan discloses:
executing, by the first application, an action defined by the at least one intent in response to accepting the at least one intent (The custom Intent from the custom Intent creator module 622 can request a receiving application to perform custom actions, Tan, para [0061]).
As per claim 10, Tan discloses a method for enforcing a user-specific authorization policy for authorizing an interaction between applications running on a same computing device, the method comprising:
provisioning, at an intent management server, a user-specific authorization policy for each respective user from a list of users authorized to access a first application running on a computing device, the user-specific authorization policy identifying one or more allowed intents that the first application is authorized on behalf of the respective user to invoke with a second application running on the computing device; (The secure inter-application communication system secures the inter-application communication by issuing the Intent in two phases. First, an Intent to detect which applications are capable of interacting with the mobile client application accessing the server, Tan, para [0019]. The white-listed applications include those applications between which inter-application communication is allowed or authorized, Tan, para [0049]).
receiving, at the intent management server, an intent authorization request from the first application intending to interact with the second application on behalf of a first user from the list of users, the intent authorization request from the first application including an user token associated with the first user and information identifying at least one intent selected from the one or more intents that the first application is intending to invoke with the second application; (When Application 1 issues an Intent using the default Intent system, all applications 1-N, including the malicious and unauthorized applications, can detect the Intent, and have access to data being passed. However, when Application 1 issues a custom Intent 415, only the white-listed applications 410 can detect the custom Intent 415 and know how to respond to it. The unauthorized or malicious applications 420, on the other hand, would not know how to respond to the custom Intent, and would thus ignore the custom Intent, Tan, para [0051]. The auth token may be obtained from the host server or an authentication server. The encryption/decryption module 635 can start a background service that establishes a communication session with the host server 100 (or an authentication server) to obtain a newly generated key, Tan, para [0065]. The intent authorization request is analogous to the custom intent requesting actions and the systems use of auth token obtained from a host/auth server as an input to secure the transaction).
providing, at the intent management server, a response to the intent authorization request based on the user-specific authorization policy provisioned for the first user from the list of users, the response indicating whether the first application is authorized on behalf of the first user to invoke the at least one intent with the second application running on the computing device (When application 1 issues a custom Intent 415, only the white-listed applications 410 can detect the custom Intent 415 and know how to respond to it. Once a receiving application is identified or selected, a secure channel can be opened only the application which is chosen can receive the data, Tan, para [0051]- [0052]. The response indicating whether authorized is analogous to the system behavior where only whitelisted/selected applications can respond/participate in custom-intent exchange. Authorization is enforced by the system’s selection/whitelisting mechanics is equivalent to returning/producing an authorization decision for a requested intent/action).
However, Tan does not explicitly disclose the limitation:
validating, at the intent management server, the user token received from the first application by verifying that the first user is authorized to access both the first and second applications running on the computing device; and
Omnes discloses:
validating, at the intent management server, the user token received from the first application by verifying that the first user is authorized to access both the first and second applications running on the computing device; and (The method comprises checking the validity of the authentication token by a server entity before granting access. The authentication token is associated with a user and with access rights granted to that user. Access to a service or application is granted only if the access rights associated with the user are valid. The authentication token is generated on the basis of a unique identifier of the terminal and the network access context of the terminal, Omnes, para [0026], [0074]. Here, the server-side validation of a user token by checking whether the user’s access rights authorize access to the relevant application/services on the same device)
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Tan with Omnes by creating secure channel for inter-application communication using intents (Tan) with authentication by token (Omnes). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Tan with Omnes in order to ensure information is securely exchanged between entities and create a single authorization policy that varies by both application pairing and user identity i.e., a user specific authorization policy for each user from an authorized list (See Omnes, para [0026])
As per claim 11, Tan and Omnes discloses the method of claim 10, wherein providing the response comprises:
Furthermore, Omnes discloses:
determining, after validating the user token, from the user-specific authorization policy provisioned for the first user, whether the at least one intent is included in the one or more allowed intents that the first application is authorized to invoke with the second application running on the computing device; and (Checking the validity of the service access rights, comprising at least checking an access right associated with the network access context of the terminal, Omnes, para [0006]. Here, it is determined whether the terminal has valid rights to access the requested service and bases decisions on those rights. This is analogous to determining whether a requested intent/action is permitted under a user-specific policy).
when it is determined that the at least one intent is not included in the one or more allowed intents that the first application is authorized to invoke with the second application running on the computing device, including a message in the response to indicate that the first application is not authorized on behalf of the first user to invoke with the at least one intent from the second application running on the computing device (When a token is invalid or access rights are not valid, access is not granted. Also, a response message is transmitted, indicating the result, Omnes, para [0049]. If rights are not valid, access is denied, and in the token revocation and validity check flows, the server returns a response indicating whether the token is valid or not).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Tan with Omnes by creating secure channel for inter-application communication using intents (Tan) with authentication by token (Omnes). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Tan with Omnes in order to ensure information is securely exchanged between entities and create a single authorization policy that varies by both application pairing and user identity i.e., a user specific authorization policy for each user from an authorized list (See Omnes, para [0026])
As per claim 12, Tan and Omnes discloses the method of claim 10, wherein providing the response comprises:
determining, after validating the user token, from the user-specific authorization policy provisioned for the first user, whether the at least one intent is included in the one or more allowed intents that the first application is authorized to invoke with or accept from the second application running on the computing device; and (The white-listed applications include those applications between which inter-application communication is allowed or authorized, Tan, para [0049]).
Furthermore, Omnes discloses:
when it is determined that the at least one intent is included in the one or more allowed intents that the first application is authorized to invoke with or accept from the second application running on the computing device, including a message in the response to indicate that the first application is authorized on behalf of the first user to invoke with the at least one intent from the second application running on the computing device (Generating a valid authentication token on the basis of the unique identifier of the terminal and the network access context, and transmitting the token to the terminal, Omnes, para [0006]. When access rights are valid, the system generates and transmits a token authorizing access. This token is directly used to permit access going forward).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Tan with Omnes by creating secure channel for inter-application communication using intents (Tan) with authentication by token (Omnes). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Tan with Omnes in order to ensure information is securely exchanged between entities and create a single authorization policy that varies by both application pairing and user identity i.e., a user specific authorization policy for each user from an authorized list (See Omnes, para [0026])
As per claim 13, Tan and Omnes disclose the method of claim 12, further comprising:
Furthermore, Omnes discloses:
invoking, by the first application, the at least one intent with the second application in response to the message indicating that the first application is authorized on behalf of the first user to invoke with the at least one intent from the second application running on the computing device (A response message is transmitted, indicating the result, Omnes, para [0049])
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Tan with Omnes by creating secure channel for inter-application communication using intents (Tan) with authentication by token (Omnes). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Tan with Omnes in order to ensure information is securely exchanged between entities and create a single authorization policy that varies by both application pairing and user identity i.e., a user specific authorization policy for each user from an authorized list (See Omnes, para [0026])
As per claim 14, Tan and Omnes disclose the method of claim 12, wherein the user-specific authorization policy further defines an expiration time after which the user-specific authorization policy provisioned for each respective user is no longer valid, the method further comprising:
Furthermore, Omnes discloses:
determining, at the intent management server, that the expiration time has not expired before providing the response (Token generation date may be stored during the token validity check if the expiry date is exceeded the token can be revoked, Omnes, para [0063]. This teaches that token validity depends on expiration and that server checking of expiration occurs before use/issuance).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Tan with Omnes by creating secure channel for inter-application communication using intents (Tan) with authentication by token (Omnes). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Tan with Omnes in order to ensure information is securely exchanged between entities and create a single authorization policy that varies by both application pairing and user identity i.e., a user specific authorization policy for each user from an authorized list (See Omnes, para [0026])
As per claim 15, Tan and Omnes disclose the method of claim 12, wherein the user-specific authorization policy further identifies one or more particular computing devices for which the user-specific authorization policy is valid, the method further comprising:
Furthermore, Omnes discloses:
retrieving, at the intent management server, from the intent authorization request, a device identifier associated with the computing device running the first and the second applications; and (Authentication by token for accessing a service from a terminal on receipt of a service access authorization request. The generated authentication token is based on a unique identifier of the terminal, Omnes, para [0008]- [0011]. The unique identifier of the terminal functions as the device identifier. It is used in token generation logic).
determining, at the intent management server, that the device identifier is associated with the one or more particular computing devices identified in the user-specific authorization policy before providing the response (Check that the terminal is authorized under the user’s access rights and network context before generating a token, Omnes, para [0076]. Device context, which is terminal identifier and access context, is checked before token generation which binds token issuance to authorized devices).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Tan with Omnes by creating secure channel for inter-application communication using intents (Tan) with authentication by token (Omnes). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Tan with Omnes in order to ensure information is securely exchanged between entities and create a single authorization policy that varies by both application pairing and user identity i.e., a user specific authorization policy for each user from an authorized list (See Omnes, para [0026])
As per claim 17, Tan and Omnes an intent management server, comprising:
a communications interface, a memory provisioned with a user-specific authorization policy for each respective user from a list of users authorized to access a first application running on a computing device, the user-specific authorization policy identifying one or more allowed intents that the first application is authorized on behalf of the respective user to invoke with or accept from a second application running on the computing device; and (One or more processors, Tan, para [0021])
an electronic processor communicatively coupled to the communications interface and the memory, the electronic processor configured to: (Processor module, Tan, para [0066])
receive, via the communications interface, an intent authorization request from the second application intending to interact with the first application on behalf of a first user from the list of users, the intent authorization request from the second application including an user token associated with the first user and information identifying at least one intent that the second application is intending to invoke with the first application; (The auth token may be obtained from the host server or an authentication server. The encryption/decryption module 635 can start a background service that establishes a communication session with the host server 100 (or an authentication server) to obtain a newly generated key, Tan, para [0065]. The intent authorization request is analogous to the custom intent requesting actions and the systems use of auth token obtained from a host/auth server as an input to secure the transaction).
provide, via the communications interface, a response to the intent authorization request based on the user-specific authorization policy provisioned for the first user from the list of users, the response indicating whether the second application running on the computing device is authorized on behalf of the first user to invoke the at least one intent with the first application running on the computing device (When application 1 issues a custom Intent 415, only the white-listed applications 410 can detect the custom Intent 415 and know how to respond to it. Once a receiving application is identified or selected, a secure channel can be opened only the application which is chosen can receive the data, Tan, para [0051]- [0052]. The response indicating whether authorized is analogous to the system behavior where only whitelisted/selected applications can respond/participate in custom-intent exchange. Authorization is enforced by the system’s selection/whitelisting mechanics is equivalent to returning/producing an authorization decision for a requested intent/action).
However, Tan does not explicitly disclose the limitation:
validate the user token received from the second application by verifying that the first user is authorized to access both the first and second applications running on the computing device; and
Omnes discloses:
validate the user token received from the second application by verifying that the first user is authorized to access both the first and second applications running on the computing device; and (The method comprises checking the validity of the authentication token by a server entity before granting access. The authentication token is associated with a user and with access rights granted to that user. Access to a service or application is granted only if the access rights associated with the user are valid. The authentication token is generated on the basis of a unique identifier of the terminal and the network access context of the terminal, Omnes, para [0026], [0074]. Here, the server-side validation of a user token by checking whether the user’s access rights authorize access to the relevant application/services on the same device)
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Tan with Omnes by creating secure channel for inter-application communication using intents (Tan) with authentication by token (Omnes). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Tan with Omnes in order to ensure information is securely exchanged between entities and create a single authorization policy that varies by both application pairing and user identity i.e., a user specific authorization policy for each user from an authorized list (See Omnes, para [0026])
As per claim 18, Tan and Omnes disclose the intent management server of claim 17, wherein the electronic processor is configured to:
Furthermore, Omnes discloses:
determine, after validating the user token, from the user-specific authorization policy provisioned for the first user, whether the at least one intent is included in the one or more allowed intents that the first application is authorized to accept from the second application running on the computing device; and (Checking the validity of the service access rights, comprising at least checking an access right associated with the network access context of the terminal, Omnes, para [0006]. Here, it is determined whether the terminal has valid rights to access the requested service and bases decisions on those rights. This is analogous to determining whether a requested intent/action is permitted under a user-specific policy).
when it is determined that the at least one intent is not included in the one or more allowed intents that the first application is authorized to accept from the second application running on the computing device, include a message in the response to indicate that the second application running on the computing device is not authorized on behalf of the first user to invoke the at least one intent with the first application running on the computing device (When a token is invalid or access rights are not valid, access is not granted. Also, a response message is transmitted, indicating the result, Omnes, para [0049]. If rights are not valid, access is denied, and in the token revocation and validity check flows, the server returns a response indicating whether the token is valid or not).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Tan with Omnes by creating secure channel for inter-application communication using intents (Tan) with authentication by token (Omnes). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Tan with Omnes in order to ensure information is securely exchanged between entities and create a single authorization policy that varies by both application pairing and user identity i.e., a user specific authorization policy for each user from an authorized list (See Omnes, para [0026])
As per claim 19, Tan and Omnes disclose the intent management server of claim 17, wherein the electronic processor is configured to:
Furthermore, Omnes discloses:
determine, after validating the user token, from the user-specific authorization policy provisioned for the first user, whether the at least one intent is included in the one or more allowed intents that the first application is authorized to accept from the second application running on the computing device; and (Checking the validity of the service access rights, comprising at least checking an access right associated with the network access context of the terminal, Omnes, para [0006]. Here, it is determined whether the terminal has valid rights to access the requested service and bases decisions on those rights. This is analogous to determining whether a requested intent/action is permitted under a user-specific policy).
when it is determined that the at least one intent is included in the one or more allowed intents that the first application is authorized to accept from the second application running on the computing device, issue, at the intent management server, an intent authorization token with the response to indicate that the second application running on the computing device is authorized on behalf of the first user to invoke the at least one intent with the first application running on the computing device (When a token is invalid or access rights are not valid, access is not granted. Also, a response message is transmitted, indicating the result, Omnes, para [0049]. If rights are not valid, access is denied, and in the token revocation and validity check flows, the server returns a response indicating whether the token is valid or not).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Tan with Omnes by creating secure channel for inter-application communication using intents (Tan) with authentication by token (Omnes). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Tan with Omnes in order to ensure information is securely exchanged between entities and create a single authorization policy that varies by both application pairing and user identity i.e., a user specific authorization policy for each user from an authorized list (See Omnes, para [0026])
As per claim 20, Tan and Omnes disclose the intent management server of claim 17, wherein the user-specific authorization policy further defines at least one of:
Furthermore, Omnes discloses:
an expiration time after which the user-specific authorization policy provisioned for each respective user is no longer valid; or one or more device identifiers identifying particular computing devices for which the user-specific authorization policy is valid (Token generation date may be stored during the token validity check if the expiry date is exceeded the token can be revoked, Omnes, para [0063]. This teaches that token validity depends on expiration and that server checking of expiration occurs before use/issuance).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Tan with Omnes by creating secure channel for inter-application communication using intents (Tan) with authentication by token (Omnes). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Tan with Omnes in order to ensure information is securely exchanged between entities and create a single authorization policy that varies by both application pairing and user identity i.e., a user specific authorization policy for each user from an authorized list (See Omnes, para [0026])
Claims 6,8 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Tan et al. (US 20140068779 A1), hereinafter referred to as Tan, in view of Omnes et al. (US 20150172283 A1), hereinafter referred to as Omnes in further view of Sibert et al. (US 20200159966 A1), hereinafter referred to as Sibert.
As per claim 6, Tan and Omnes discloses the method of claim 3, further comprising:
However, Tan in view of Omnes does not explicitly disclose the limitation:
retrieving, at the intent management server, an application signature from the intent authorization request; and
prior to issuing the intent authorization token, validating, at the intent management server, the application signature by verifying that the application signature is cryptographically signed by the second application intending to interact with the first application
Sibert discloses:
retrieving, at the intent management server, an application signature from the intent authorization request; and (The server system receives a signed request for an application executing on the computing device, Sibert, para [0062]. A signed request contains a cryptographic signature attributable to the requesting party (here the app/secure circuit acting for the app). This corresponds to retrieving an application signature from a request before granting/issuing anything)
prior to issuing the intent authorization token, validating, at the intent management server, the application signature by verifying that the application signature is cryptographically signed by the second application intending to interact with the first application (Generate the attestation by signing the challenge with the private key. The server system prior to generating verifies metadata pertaining to an identity of the application, Sibert, claim 6 and para [0063]. The flow discloses cryptographic signing using a private key and server-side verification of application identity metadata before issuing the attestation, which is analogous to validating the signature it came from the authentic application).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Tan and Omnes with Sibert by creating secure channel for inter-application communication using intents (Tan) and authentication by token (Omnes) with application integrity attestation (Sibert). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Tan and Omnes with Sibert in order to effectively verify applications (See Sibert, para [0063])
As per claim 8, Tan and Omnes explicitly disclose the method of claim 3, further comprising:
However, Tan in view of Omnes does not explicitly disclose the limitations:
receiving, by the first application, an intent acceptance request from the second application, the intent acceptance request indicating that the second application is intending to invoke the at least one intent with the first application on behalf of the first user, the intent acceptance request further including the intent authorization token received by the second application from the intent management server;
validating, by the first application, the intent authorization token by verifying that the intent authorization token is cryptographically signed by the intent management server;
retrieving, after validating the intent authorization token, the user-specific authorization policy provisioned for the first user; and
Sibert discloses:
receiving, by the first application, an intent acceptance request from the second application, the intent acceptance request indicating that the second application is intending to invoke the at least one intent with the first application on behalf of the first user, the intent acceptance request further including the intent authorization token received by the second application from the intent management server; (The computing device receives a request associated with an application that includes an attestation or certificate generated by the server system. The attestation may be provided to another component or application to establish trust, Sibert, para [0020])
validating, by the first application, the intent authorization token by verifying that the intent authorization token is cryptographically signed by the intent management server; (The server system generates the attestation using a cryptographic key maintained by the server system. The attestation may be verified using corresponding public key information. Sibert, para [0063]. Cryptographically signed by the intent management server is same as an attestation generated using server maintained cryptographic key and validating is done using the public key/certificate)
retrieving, after validating the intent authorization token, the user-specific authorization policy provisioned for the first user; and (The attestation indicates that the application is associated with a particular user account. The server system verifies metadata pertaining to the identity of the application and the user prior to issuing the attestation, Sibert, para [0035])
accepting, by the first application, the at least one intent invoked by the second application in accordance with the retrieved user-specific authorization policy (The attestation enables the computing device or application to determine whether to allow an operation. Upon successful verification, the application may proceed with the requested operation, Sibert, para [0043]).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Tan and Omnes with Sibert by creating secure channel for inter-application communication using intents (Tan) and authentication by token (Omnes) with application integrity attestation (Sibert). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Tan and Omnes with Sibert in order to effectively verify applications (See Sibert, para [0063])
As per claim 16, Tan and Omnes discloses the method of claim 12, further comprising:
However, Tan in view of Omnes does not explicitly disclose the limitations:
retrieving, at the intent management server, an application signature from the intent authorization request; and
prior to providing the response, validating, at the intent management server, the application signature by verifying that the application signature is cryptographically signed by the first application intending to interact with the second application
Sibert discloses:
retrieving, at the intent management server, an application signature from the intent authorization request; and (The server system receives a signed request for an application executing on the computing device, Sibert, para [0062]. A signed request contains a cryptographic signature attributable to the requesting party (here the app/secure circuit acting for the app). This corresponds to retrieving an application signature from a request before granting/issuing anything)
prior to providing the response, validating, at the intent management server, the application signature by verifying that the application signature is cryptographically signed by the first application intending to interact with the second application (Generate the attestation by signing the challenge with the private key. The server system prior to generating verifies metadata pertaining to an identity of the application, Sibert, claim 6 and para [0063]. The flow discloses cryptographic signing using a private key and server-side verification of application identity metadata before issuing the attestation, which is analogous to validating the signature it came from the authentic application).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Tan and Omnes with Sibert by creating secure channel for inter-application communication using intents (Tan) and authentication by token (Omnes) with application integrity attestation (Sibert). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Tan and Omnes with Sibert in order to effectively verify applications (See Sibert, para [0063])
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RAGHAVENDER CHOLLETI whose telephone number is (703) 756-1065. The examiner can normally be reached M-F 9am-5pm ET.
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, RUPAL DHARIA can be reached on (571) 272-3880. 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.
Respectfully submitted,
/RAGHAVENDER NMN CHOLLETI/Examiner, Art Unit 2492
/MICHAEL W CHAO/Primary Examiner, Art Unit 2492
Prosecution Insights