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 .
In view of the Appeal Brief filed on 10/02/2025, PROSECUTION IS HEREBY REOPENED. A new grounds of rejection set forth below.
To avoid abandonment of the application, appellant must exercise one of the following two options:
(1) file a reply under 37 CFR 1.111 (if this Office action is non-final) or a reply under 37 CFR 1.113 (if this Office action is final); or,
(2) initiate a new appeal by filing a notice of appeal under 37 CFR 41.31 followed by an appeal brief under 37 CFR 41.37. The previously paid notice of appeal fee and appeal brief fee can be applied to the new appeal. If, however, the appeal fees set forth in 37 CFR 41.20 have been increased since they were previously paid, then appellant must pay the difference between the increased fees and the amount previously paid.
A Supervisory Patent Examiner (SPE) has approved of reopening prosecution by signing below:
/SHEWAYE GELAGAY/ Supervisory Patent Examiner, Art Unit 2436
Claim Objections
Regarding Claims 6 and 13, Claim 6 and 13 are objected to because of the following informalities: In line 2, “the entity” lacks antecedent basis. In light of specification examiner interprets the entity as the third-party entity mentioned above in claim 1, and 8 respectively. Appropriate correction is required.
Regarding Claims 7, and 14, Claims 7, and 14, are objected to as being unclear that they recite “determining that the first service provider has permission from a resource owner to access a protected resource “associated with” the first service provider”. If the resource is already “associated with the first service provider”, it makes it unclear why the SP needs permission to access its own resource. Examiner suggest to clarify the scope of the claims. Appropriate correction is required.
Regarding Claim 20, Claim 20 is objected to because of the following informalities: In line 3, “prior to issuing the credential” lacks antecedent basis. Claim 18 or claim 15 does not explicitly recite “issuing the credential” rather recites “allowing access to the protected resource by the client application”. 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.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1, 8, and 15 recite the limitation " the encrypted binary object having been generated based on applying an attribute-based encryption (ABE) master key to one or more registration rules of a policy”. It is unclear whether “ABE master Key” is “ABE master secret key” or “ABE master public key” or general master key. The specification specifies that “generates the binary object as a cryptographic object by applying the ABE master public key to the one or more rules of the policy”, see specification of instant application [Brief summary]. Examiner suggest to clarify the “ABE master key” elements recited in claims 1, 8, and 15. Dependent claims are also rejected for inheriting the deficiencies set forth above for independent claims. Appropriate correction is required.
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, 6, 8, 12, 13, 15, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Mistry (US 20170094509 A1) in view of Waters (US 20120314854 A1).
Regarding claim 1, Mistry teaches a computer-implemented method comprising:
receiving, by a first service provider, an encrypted binary object and a set of public parameters from a third-party entity, the encrypted binary object to one or more registration rules of a policy for enrollment with the first service provider (Mistry, allow for enrollment of a mobile computing device (i.e., a client application) and access of enterprise resources from the enrolled mobile computing device without the need for the enterprise user to know or enter their network or directory service password and without the need for the PIV or CAC card to be physically connected to the mobile computing device during enrollment or subsequent access of enterprise resources, [0007] using derived credentials for enrollment of mobile computing devices with enterprise mobile device management services, [0035] sending, by the mobile computing device (i.e., a client application), using the enrollment application, an enrollment request message to the enterprise mobile device management server (i.e., the first service provider) The enterprise mobile device management server 724 may be configured to respond to the enrollment request message with a response message comprising derived credential information, certificate management system application information, and password complexity rule information, [0124] the certificate management system application 714 may request and receive at least one or more derived credentials (i.e., an encrypted binary objects + a set of public parameters) from the certificate management system server 728 (i.e., the third part entity). The derived credentials may comprise enrollment credentials, Secure/Multipurpose Internet Mail Extensions (S/MIME) encryption and signing certificates, other network credentials, encryption certificates, signing certificates, and the like. The certificate management system application 714 may be configured to encrypt the received derived credentials using a very strong form of encryption such as Advanced Encryption Standard (AES) 256-bit encryption, [0130] Application management client certificate support on iOS may rely on importing a public-key cryptography standards (PKCS) 12 BLOB (Binary Large Object) into the iOS keychain in each managed application for each period of use, [0113]) [Examiner interprets that the enterprise mobile device management server (i.e., the first service provider) receiving derived credentials including encrypted credential containers such as PKCS#12 binary objects containing certificates and associated public -key infrastructure (PKI) parameters (e.g., public keys and certificate metadata) (encrypted binary object + set of public parameters) , these credentials are encrypted using AES 256 and are issued by the certificate management system server (i.e., the third party entity) and these credentials are used for enrollment with enterprise MDM server as limitation above];
receiving, by the first service provider, a request from a client application for enrollment with the first service provider, the request having associated therewith a user key, the user key having been generated by the third-party entity (Mistry, sending, by the mobile computing device (i.e., a client application), using the enrollment application, an enrollment request message to the enterprise mobile device management server (i.e., the first service provider) The enterprise mobile device management server 724 may be configured to respond to the enrollment request message with a response message comprising derived credential information, certificate management system application information, and password complexity rule information, [0124] The enrollment application 712 may be configured to retrieve a link to the derived credentials from the shared vault 716. The enrollment application 712 may use the user password provided by the user of the mobile computing device 710 to decrypt the encrypted derived credentials from the shared vault 716. Alternatively, the enrollment application 712 may prompt the user of the mobile computing device 710 for the user password if or when the enrollment application 712 does not have the user password. For example, the enrollment application 712 may no longer have the user password because the user of the mobile computing device 710 may have inadvertently stopped and restarted the enrollment application 712. The enrollment application 712 may be configured to present the derived credentials to the enterprise mobile device management server 724, [0132] After the user has been authenticated, the certificate management system application 714 may request and receive at least one or more derived credentials from the certificate management system server 728. The derived credentials may comprise enrollment credentials, Secure/Multipurpose Internet Mail Extensions (S/MIME) encryption and signing certificates, other network credentials, encryption certificates, signing certificates, the certificate management system application 714 may encrypt the derived credentials using a private/public key pair, prior to storing the derived credentials in the shared vault 716 on the mobile computing device 710, [0130]) [Examiner interprets that an enrollment application executing on a mobile device management server sends an enrollment request message to an enterprise mobile device management server and a certificate management server which is separate from the enterprise mobile device management server authenticates the user and generates derived credentials comprising cryptographic certificates and associated key , and enrolment application retrieving the derived credentials and presenting it to the mobile device management server to complete enrollment as limitation above];
responsive to decryption the encrypted binary object using the user key and the set of public parameters, determining the first service provider that the client application can be trusted (Mistry, After the user has been authenticated, the certificate management system application 714 may request and receive at least one or more derived credentials from the certificate management system server 728. The derived credentials may comprise enrollment credentials, Secure/Multipurpose Internet Mail Extensions (S/MIME) encryption and signing certificates, other network credentials, encryption certificates, signing certificates ..The certificate management system application 714 may be configured to encrypt the received derived credentials using a very strong form of encryption such as Advanced Encryption Standard (AES) 256-bit encryption, [0130] In response to the request, the enterprise mobile device management server 724 may be configured to send a message comprising information on the type of derived credentials needed to complete enrollment. The enrollment application 712 may be configured to retrieve a link to the derived credentials from the shared vault 716. The enrollment application 712 may use the user password provided by the user of the mobile computing device 710 to decrypt the encrypted derived credentials from the shared vault 716… The enterprise mobile device management server 724 may be configured to validate the derived credentials. The enterprise mobile device management server 724 may communicate with the certificate management system server 728 to verify the validity of the derived credentials for the mobile computing device 710. The enterprise mobile device management server 724 may also communicate with the directory service 726 to verify the validity of the user of the mobile computing device 710, [0132] Once validation of the derived credentials is completed, the enrollment flow may complete without the need for the user of the mobile computing device 710 to provide any further credentials…. Once the enrollment flow has completed, the mobile computing device 710 may be referred to as an enrolled device, [0133]) [Examiner interprets that derived credentials comprising cryptographic certificates and associated key material are generated and encrypted by the certificate management server, the derived credentials are present to enterprise mobile management server which validates the derived credentials and communicates with certificate management system server to verify the validity as limitation above. Under BRI, validation pf PKI based encrypted credentials inherently requires cryptographic processing using associated user key and corresponding public parameters. Upon successful validation of derived credentials , the mobile computing device is designated as enrolled (i.e., trusted device)];
Although Mistry teaches the decryption and determining trust between service provider and the client application trust based on decryption that happens, but in Mistry the decryption is not done by the first service provider
Mistry does not explicitly teach:
Receiving an encrypted binary object and a set of public parameters, the encrypted binary object having been generated based on applying an attribute-based encryption (ABE) master key according to policy; the request having associated therewith an ABE user key, the ABE user key having been generated according to the policy and including one or more attributes required by the policy; responsive to the first service provider being able to decrypt the encrypted binary object using the ABE user key and the set of public parameters, determining trust/authorization
However, Waters teaches:
Receiving an encrypted binary object and a set of public parameters, the encrypted binary object having been generated based on applying an attribute-based encryption (ABE) master key according to policy (Waters, Attribute Based Encryption`, replaces the public (encryption) key with two values: a parameter generated by a trusted party known as an Authority, and a `policy` describing the attributes of the users to whom the message was addressed. The Authority also generates decryption keys that each embed one or more attributes describing a user. A key can be used to decrypt the ciphertext if and only if it contains attributes that satisfy the policy used to encrypt, [0007] At step 1102 a ciphertext comprising a policy is received. In certain embodiments, a ciphertext is received by a decryptor such as decryptor 220, [0086] Each of the authorities that may be involved in the generation of a policy may generate a set of authority parameters, Authority parameters are analogous to public keys that may be provided by an authority. An authority involved in generating a policy may also generate an authority secret key that is associated with each authority parameter, Authority parameters are analogous to public keys that may be provided by an authority. An authority involved in generating a policy may also generate an authority secret key that is associated with each authority parameter, [0070] encryptor 210 obtains one or more global parameters. In certain embodiments global parameters may comprise names of attributes that may be associated with a group of entities or a particular entity, At step 830, encryptor 210 constructs a policy using the authority parameter or authority parameters that encryptor 210 has received from each authority associated with the policy. In an embodiment, the policy may comprise one or more global parameters as well as authority parameters. A global parameter may be a parameter that can be evaluated by more than one authority. At step 840, encryptor 210 encrypts a plaintext message to generate a ciphertext [0078] At step 1112 a decryption key is generated based on the policy, the first key and the second key. For example, decryptor 220 generates a decryption key for the ciphertext based on the first key, the second key, and the policy. In the illustrative embodiment, the user combines the key components it has received with the policy in order to generate a decryption key for decrypting the ciphertext, [0091] a global setup step may take place prior to generating a ciphertext. In such a global setup generates global parameters ("GP"), the Global Setup(L)GP. Where the global parameters are a description of a bilinear group G of prime order p, the prime p, a generator g of G, and the description of a hash function H that maps global identities to elements of G. The GP may be chosen and published by one party of the system or computed through the cooperation of multiple parties, [0106]) [Examiner interprets that decryptor /receiver receiving cipher text and publicly available parameters (i.e., global parameters and authority parameters) used by encryptor/ decryptor, and system implementing policy-based ABE encryption producing ciphertext by using authority secret keys/ master key to generate keys and enable ABE as limitation above];
the request having associated therewith an ABE user key, the ABE user key having been generated according to the policy and including one or more attributes required by the policy (Waters, Attribute Based Encryption`, replaces the public (encryption) key with two values: a parameter generated by a trusted party known as an Authority, and a `policy` describing the attributes of the users to whom the message was addressed. The Authority also generates decryption keys that each embed one or more attributes describing a user. A key can be used to decrypt the ciphertext if and only if it contains attributes that satisfy the policy used to encrypt, [0007] decryptor 220 transmits a request to authority 150 for a key component associated with a particular attribute. The request may comprise a policy or a part of a policy associated with a particular attribute or attributes and a GID associated with decryptor 220. In certain embodiments, the request may comprise an attribute identifier. The GID associated with an encryptor may be referred to as a decryptor identifier, [0073] decryptor 220 may maintain a collection of all key components corresponding to its GID. Such a collection may be referred to as a decryption key, [0076] At step 1104 the decryptor determines whether he already has possession of the required key components to decrypt the ciphertext. If the decryptor determines that he does not have possession of the required key components, a request may be transmitted to a first authority, the request may comprise a first attribute identifier and a first decryptor identifier. For example, decryptor 220 may transmit a request to authority 150, [0087] At step 1106 a first key is received from the first authority in response to the request to the first authority. For example, decryptor 220 receives a key component to be used in decrypting the ciphertext from authority 150. In the illustrative embodiment, when the first authority determines that the user whose GID it received is eligible to receive the appropriate key component the authority sends the key component to the user, [0088]) [Examiner interprets that the decryptor requesting keys and receiving attribute linked decryption keys from authorities and using them to decrypt the ciphertext and keys corresponds to attributes needed by the encryption policy as limitation above];
responsive to the first service provider being able to decrypt the encrypted binary object using the ABE user key and the set of public parameters, determining trust/authorization (Waters, FIG. 9. At step 910, decryptor 220 obtains global parameters. At step 920, decryptor 220 obtains one or more key components from an authority such as authority 150. At step 930, decryptor 220 obtains a ciphertext to be decrypted. It should be understood by one skilled in the art, that step 930 may occur prior to steps 910 and 920 in certain embodiments. At step 940, decryptor 220 verifies that the ciphertext policy matches key components that decryptor 220 has received. In an embodiment where decryptor 220 does not have key components necessary to decrypt a particular ciphertext, decryptor 220 may request key components from one or more authorities. At step 950, decryptor 220 decrypts the ciphertext using key components, [0079] To decrypt such a message, decryptor 220 performs a decrypt function:Decrypt(CT, GP, {K.sub.i,GID})M, [0113] Attribute Based Encryption`, replaces the public (encryption) key with two values: a parameter generated by a trusted party known as an Authority, and a `policy` describing the attributes of the users to whom the message was addressed. The Authority also generates decryption keys that each embed one or more attributes describing a user. A key can be used to decrypt the ciphertext if and only if it contains attributes that satisfy the policy used to encrypt, [0007]) [Examiner interprets that decryptor decrypting the ciphertext using decryption keys/ key components and global parameters and only users whose attributes satisfies the policy can decrypt for access control as limitation above];
Examiner notes: Water’s decryptor is a system component that performs decryption on behalf of the entity enforcing access control, which corresponds to the first service provider in Mistry that controls enrollment authorization. In waters, successful decryption indicates satisfaction of a policy defining authorized entities. In Mistry, satisfaction of enrollment requirements results in the device being designated as enrolled and trusted. Thus, combined teachings determine that the client application can be trusted responsive to successful decryption.
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Mistry to include a concept of receiving an encrypted binary object and a set of public parameters, the encrypted binary object having been generated based on applying an attribute-based encryption (ABE) master key according to policy; the request having associated therewith an ABE user key, the ABE user key having been generated according to the policy and including one or more attributes required by the policy; decrypt the encrypted binary object using the ABE user key and the set of public parameters, determining trust/authorization as taught by Waters for the purpose of replacing the public (encryption) key with Attribute Based Encryption with two values: a parameter generated by a trusted party known as an Authority, and a `policy` describing the attributes of the users to whom the message was addressed, generating decryption keys that each embed one or more attributes describing a user by authorities, and using the key to decrypt the ciphertext if and only if it contains attributes that satisfy the policy used to encrypt, [Waters:0007] and encrypting the messages and communicating those messages to intended recipients [Waters:0036].
Regarding claim 5, Mistry and Waters further teaches the method as described in claim 1 wherein the third-party entity is a third-party vetting service (Mistry, The certificate management system application 714 may be configured to authenticate the user of the mobile computing device and the mobile computing device with the certificate management system server 728. The certificate management system application 714 may use at least one or more authentication mechanisms to authenticate with the certificate management system server 728, as required by the enterprise… the authentication may be performed in person at a kiosk 740 and may include biometric authentication… The authentication mechanisms may verify that the user of the mobile computing device 710 is permitted to possess the derived credentials, in addition to authenticating the user of the mobile computing device 710. The certificate management system server 728 may access the user's information in the directory service 726 to authenticate the user and to verify the user's permissions. The authentication mechanisms described herein should be the same authentication mechanisms that may already in use by the enterprise to effect authentication with PIV or CAC cards in their organization, [0129] After the user has been authenticated, the certificate management system application 714 may request and receive at least one or more derived credentials from the certificate management system server 728. The derived credentials may comprise enrollment credentials, Secure/Multipurpose Internet Mail Extensions (S/MIME) encryption and signing certificates, other network credentials, encryption certificates, signing certificates, and the like, [0130]) [Examiner interprets that certificate management system authenticating users, issuing credentials, and acts as an independent trust authority as the third-party entity is a third-party vetting service].
Regarding claim 6, Mistry teaches the method as described in claim 1 further including establishing a root of trust to the entity (Mistry, The certificate management system application 714 may be configured to authenticate the user of the mobile computing device and the mobile computing device with the certificate management system server 728. The certificate management system application 714 may use at least one or more authentication mechanisms to authenticate with the certificate management system server 728, as required by the enterprise, [0129] After the user has been authenticated, the certificate management system application 714 may request and receive at least one or more derived credentials from the certificate management system server 728. The derived credentials may comprise enrollment credentials, Secure/Multipurpose Internet Mail Extensions (S/MIME) encryption and signing certificates, other network credentials, encryption certificates, signing certificates, [0130] Once validation of the derived credentials is completed, the enrollment flow may complete without the need for the user of the mobile computing device 710 to provide any further credentials… Once the enrollment flow has completed, the mobile computing device 710 may be referred to as an enrolled device, [0133]) [Examiner interprets that certificate management server (i.e., the entity) authenticating users , issuing credentials and determining eligibility to enroll the client application as limitation above]
Mistry does not explicitly teach:
the root of trust being represented by an ABE master secret key, and the set of one or more public parameters.
However, Waters teaches:
the root of trust being represented by an ABE master secret key, and the set of one or more public parameters (Waters, a global setup step may take place prior to generating a ciphertext. In such a global setup generates global parameters ("GP"), the Global Setup(L)GP…The GP may be chosen and published by one party of the system or computed through the cooperation of multiple parties, [0106] each authority may execute an authority setup step in order to create a secret key ("SK") and a authority parameter ("PK"), where Authority Setup(GP)(SK,PK). For each attribute i belonging to the authority, the authority chooses two random exponents .alpha..sub.i,y.sub.i .epsilon. Z.sub.p. It publishes PK={e(g,g).sup..alpha..sup.i,g.sup.y.sup.i}.sub.i as its authority parameter and keeps SK={.alpha..sub.i,y.sub.i}.sub.i as its secret key, [0107] n encryptor 210 may perform an encryption function to generate a ciphertext such as: encrypt(M, (A, .rho.), GP, {PK.sub.j})CT, [0108] Keys and key components may be generated by authority 150 based on a global identifier of decryptor 220, global parameters, the shares and the secret key for the particular authority generating the key. KeyGen(GID, GP, i, SK)K.sub.i,GID…. [0011]) [Examiner interprets that system relying on trusted authority’s retained master secret (SK) from which user/attribute decryption key are derived (i.e., ABE master Key) and the published parameters (GP/PK) used by encryptors and decryptors for access control as limitation above]. same motivation applies as claim 1.
Regarding claims 8 and 15, Claims 8 and 15 recite commensurate subject matter as Claim 1. Therefore, they are rejected for the same reasons. Except for the additional elements:
a processor set; one or more computer-readable storage media; and program instructions stored on the one or more computer-readable storage media to cause the processor set to (Mistry, a processor.., [0043] computer-executable instructions, [0045]);
one or more computer-readable storage media; and program instructions stored on the one or more computer-readable storage media to perform operations comprising (Mistry, computer-executable instructions, [0045]);
Regarding claim 12, Claim 12 recite commensurate subject matter as claim 5. Therefore, it is rejected for the same reasons.
Regarding claims 13 and 19, Claims 13, and 19 recite commensurate subject matter as claim 6. Therefore, they are rejected for the same reasons.
Claims 3, 4, 7, 10, 11, 14,17, 18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Mistry (US 20170094509 A1) in view of Waters (US 20120314854 A1) in further view of Innes (US 20140331297 A1).
Regarding claim 3, Mistry and Waters teaches the method as described in claim 1 wherein
Mistry and Waters does not appear to explicitly teach:
the client application is associated with a second service provider
However, Innes teaches:
the client application is associated with a second service provider (Innes, The client device 705 may send a request for resources 720, such as documents, emails, services, files, and the like, to the proxy device 710. The proxy device 710 may forward the request to the resource 720, and in response, authentication between the proxy device 710 and resource 720 may be initiated, [0108] a user of the client device 705 may wish to access enterprise resources that require authentication, and the proxy device 710 may mediate access. The client device 705 may use the proxy device 710 to access resource if, for example, the client device 705 is not able to directly access the resources. For example, the client device 705 might not be configured for a protocol utilized by the enterprise resources. the client device 705 and proxy device 710 may communicate using a protocol having standard components and fitting well-known authentication frameworks. The proxy device 710 may translate between a first protocol to the resource (e.g., Kerberos or SSL) and a second, different protocol to the client device 705 (e.g., HTTP or HTTPS). By utilizing the proxy device 710, client devices might not need to understand and operate a complex or different protocol used by the enterprise resource. In these examples, the proxy device 710 may play the client role, [0113]) [Examiner interprets that client application operating in different service domain than enterprise resource and proxy facilitating to translate the protocol as limitation above].
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Mistry and Waters to include a concept of client application is associated with a second service provider as taught by Innes for the purpose of controlling remote access to resources at an enterprise computing system using managed mobile applications at mobile computing devices, and for ensuring the mobile application requesting access to the enterprise resource can be trusted and is not attempting to circumvent the security mechanisms used to protect those enterprise resources [Innes:0024].
Regarding claim 4, Mistry, Waters, and Innes further teaches the method as described in claim 3 further including: receiving, by the first service provider, a request from the client application to access a protected resource; and returning the protected resource to the client application (Innes, The client device 705 may send a request for resources 720, such as documents, emails, services, files, and the like, to the proxy device 710. The proxy device 710 may forward the request to the resource 720, and in response, authentication between the proxy device 710 and resource 720 may be initiated…. Once the context information is verified, the client device 705 may provide the requested signature to the proxy device 710, and the proxy device 710 may complete authentication with the resource 720 and/or the authentication service 715. Then, the proxy device 710 may retrieve the resource requested by the client device 705 and provide it to the client device 705, [0108-0109] a user of the client device 705 may wish to access enterprise resources that require authentication, and the proxy device 710 may mediate access. The client device 705 may use the proxy device 710 to access resource if, for example, the client device 705 is not able to directly access the resources, [0113] In step 958, once the proxy device 710 obtains the resource, the proxy device 710 may send the resource to the client device 705, [0164]) [Examiner interprets that proxy getting request from the client device to access the resources and authenticating the client device and obtaining resources on the behalf of client device and sending the resources to the client device as limitation above];
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Mistry and Waters to include a concept of receiving, by the first service provider, a request from the client application to access a protected resource; and returning the protected resource to the client application as taught by Innes for the purpose of completing authentication with the resource by the proxy device, retrieve the resource requested by the client device 705 and provide it to the client device 705 by the proxy device, [Innes, 0108-0109] and for ensuring the mobile application requesting access to the enterprise resource can be trusted and is not attempting to circumvent the security mechanisms used to protect those enterprise resources [Innes:0024].
Regarding claim 7, Mistry, Waters, and Innes further teaches the method as described in claim 4 further including determining that the first service provider has permission from a resource owner to access the protected resource associated with the first service provider prior to allowing access to the protected resource by the client application (Innes, The client device 705 may send a request for resources 720, such as documents, emails, services, files, and the like, to the proxy device 710. The proxy device 710 may forward the request to the resource 720, and in response, authentication between the proxy device 710 and resource 720 may be initiated…. Once the context information is verified, the client device 705 may provide the requested signature to the proxy device 710, and the proxy device 710 may complete authentication with the resource 720 and/or the authentication service 715. Then, the proxy device 710 may retrieve the resource requested by the client device 705 and provide it to the client device 705, [0108-0109] In step 958, once the proxy device 710 obtains the resource, the proxy device 710 may send the resource to the client device 705, [0164]) [Examiner interprets that proxy completing authentication with the resource and/or the authentication service, retrieving the resource requested by the client device and providing it to the client device as limitation above];
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Mistry and Waters to include a concept of determining that the first service provider has permission from a resource owner to access the protected resource associated with the first service provider prior to allowing access to the protected resource by the client application as taught by Innes for the purpose of completing authentication with the resource by the proxy device, retrieve the resource requested by the client device 705 and provide it to the client device 705 by the proxy device, [Innes, 0108-0109] and for ensuring the mobile application requesting access to the enterprise resource can be trusted and is not attempting to circumvent the security mechanisms used to protect those enterprise resources [Innes:0024].
Regarding claims 10, 11, 14 and 17, 18, 20, Claims 10, 11, 14 and 17, 18, 20 recite commensurate subject matter as claims 3, 4,and 7 respectively. Therefore, they are rejected for the same reasons
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20130305378 A1: “relates to a method and system for establishing trust between a service provider and a client of the service provider”
US 20190020480 A1: “relates to the electrical, electronic and computer arts, and more specifically, to identity and attribute authentication systems”.
US 20210084040 A1: “relates an identity provider authorizes the access of a protected resource by a client application by providing an access token having a permission that allows the client application to perform an action or operation on the protected resource”
US20140040993 A1: “relates to a method for providing authorized access to a service application in order to use a protected resource of an end user, said protected resource typically being an API and being exposed by endpoints of a plurality of administrative domains, and said authorized access performed by means of an OAuth procedure”
US12452247 A1 : “delegated access to resources by allowing one application to act on behalf of a user, without exposing their credentials”
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SAMIKSHYA POUDEL whose telephone number is (703)756-1540. The examiner can normally be reached 7:30 AM - 5PM Mon- Fri.
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, SHEWAYE GELAGAY can be reached at (571)272-4219. 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.
/S.N.P./Examiner, Art Unit 2436 /SHEWAYE GELAGAY/Supervisory Patent Examiner, Art Unit 2436