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
In the remarks filed on 04/23/2026. The applicant amended claims 1, 3, 4-8, 10-14, and 17-18 are amended. No claims were added.
With respect to claim objections:
Applicant’ claim amendments and remarks filed on 04/23/2026 have been fully considered and overcame the claim objections as presented in the non-final office action filed 01/23/2026. Therefore, objections have been withdrawn.
With respect to 112(b) rejections:
Applicant’ claim amendments and remarks filed on 04/23/2026 have been fully considered and overcame the 112(b) rejections as presented in the non-final office action filed 01/23/2026. Therefore, rejection have been withdrawn.
With respect to 35 U.S.C. §102 and 103 rejections:
Applicant's arguments filed on 04/30/2025 have been received and entered.
Applicant's arguments with respect to the newly amended independent claims, see Applicant Arguments 10-15, with respect to the rejection (s) of independent claims 1,8 and 15 have been fully considered.
Applicant argues that Mistry does not disclose “receiving, by the first service provider…associated therewith an ABE user Key”. This argument is not persuasive because it improperly addresses Mistry separately from Waters. Mistry relied upon for the enrollment architecture including transmission of an enrollment request from the client application to the enterprise mobile device management server and validation of credentials by that server. Waters is relied upon for the ABE implementation including attribute linked decryption keys and decryption of policy encrypted ciphertext. It is obvious to POSITA that combined teaching of Mistry and Waters the above limitation. Moreover, Under BRI, the recitation that the enrollment request has an ABE user key “associated therewith” does not require that the ABE user key be physically embedded in the same message containing the enrollment request. The claim language reasonably encompasses a user key that is logically, functionally or transactionally associated with the enrollment request and is provided or made available as part of the corresponding enrollment procedure.
Applicant also argues that Mistry’s enrollment application, rather than its enterprise server decrypts the encrypted derived credentials. This argument is directed to Mistry without the modification supplied by Waters. Mistry already assigns the enterprise mobile device management server the function of validating the credentials presented during enrollment. In the proposed combination, Waters’ ABE decryption technique is used to perform that server-side credential validation. Thus, the resulting system uses the ABE user key and public parameters to decrypt the policy encrypted object at the first service provider and determines whether to trust the client based on the success of that operation. The proposed combination does not require the physical incorporation of Water’s system into Mistry. Rather, Waters’ policy-based ABE verification is predictably used as the cryptographic mechanism by which Mistry’s enterprise server performs its disclosed credential validation function. Applicant’s assertion that it “would not make sense” for the enterprise server to receive decryption key is also unpersuasive. Applicant has not identified any technical incompatibility that would prevent the server from receiving and using the key. Thus, applicant’s argument do not overcome the rejection for claims 1, 8, and 15. Applicant similarly argues that Innes does not cure the alleged deficiencies of Mistry and Waters for claims 3-4, 7,10-11,14,17-18, and 20. However, the asserted deficiencies in the underlying combination are not persuasive for the reasons discussed above, they also don’t overcome the rejection.
Applicant further argues that Mistry in view of Waters fails to disclose the first service provider receiving, directly from a third-party entity. This argument is moot because the claim amendment introduces new claim limitations that have not previously been considered. Therefore, the new 103 ground of rejection relies on new references in combination as presented below.
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) in further view of Johnson (US 20130305378 A1).
Regarding claim 1, Mistry teaches a computer-implemented method comprising:
receiving, by a first service provider, a set of public parameters associated with an attribute-based encryption (ABE) master secret key and an encrypted binary object from a third-party entity, the encrypted binary object having been generated by the third-party entity based on applying an ABE master public key 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 directly from a third-party entity, for enrollment with the first service provider; 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].
Mistry and Waters do not teach:
Receiving directly from a third-party entity for enrollment with the first service provider (the claimed architectural relationship that the received material was generated by the third-party entity and directly received from third part entity at first service provider);
However, Johnson teaches:
Receiving directly from a third-party entity for enrollment with the first service provider; (Johnson, establish a level of trust between a service provider and a client of a service provider outside the field of monetary transactions. For example, a client may attempt to enroll a party with a service provider (such as a university, for example), and it may be important that the service provider knows the client is authorized by the party to enroll that party, [0006] The issuing bank 50 then generates 180 a secret that is unique to the account holder, and stores an association between this secret and the account holder, [0071] The issuing bank 50 then sends a second secret 60 to the merchant 20, which also uniquely corresponds to the secret generated 180 by the issuing bank 50, via a secure channel. In this example, the issuing bank 50 also sends data 135 containing details relating to the account holder to the service provider 20 via a secure channel, [0077] if the identity provider 50 (in this case the bank) generates the secret unique to the party associated with the client 10, the secret 60 can be sent to the service provider 20 (in this case the merchant), at any time after the party has been identified to the identity provider 50, but must be sent to the service provider 20 before the service provider 20 can determine whether to trust the client 10, [0078] In the event that the merchant 20 determines that the received secret corresponds to the first secret 60, the merchant 20 determines to trust the client 10 (i.e. to trust that the client 10 is authorized to request a transaction on behalf of the account holder associated with the client 10). The merchant 20, therefore, forms a trusted association between the client 10 and the account holder, [0080] The merchant 20 also uses this unique device identifier 130 to look up details 135 that relate to the account associated with the device 120 and that were stored by the merchant 20 during the registration process, [0083]) [Examiner interprets that the issuing bank 50 (i.e., third party entity) transmitting bank generated secret 60 and data 135 directly to the merchant 20 (i.e., the first service provider 20) for establishing and storing a trusted association during the registration process 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 directly from a third-party entity for enrollment with the first service provider as taught by Johnson for the purpose of identity provider 50 generating the secret unique to the party associated with the client 10, the secret 60 and sending to the service provider 20 to determine whether to trust the client 10, [Johnson :0078].
Regarding claim 5, Mistry, Waters, and Johnson further teaches computer-implemented 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, Waters, and Johnson teaches computer-implemented method as described in claim 1 further including: establishing, by the first service provider, a root of trust with the third-party 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 the ABE master secret key, and the set of public parameters associated with the ABE master secret key
However, Waters teaches:
the root of trust being represented by the ABE master secret key, and the set of public parameters associated with the ABE master secret key (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 Johnson (US 20130305378 A1) in further view of Innes (US 20140331297 A1)
Regarding claim 3, Mistry, Waters, and Johnson teaches computer-implemented 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, Waters, and Johnson to include a concept of the client application is associated with a second service provider 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, Johnson and Innes further teaches computer-implemented 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 hosted by the first service provider; and returning, by the first service provider, 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, Waters, and Johnson to include a concept of computer-implemented 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 hosted by the first service provider; and returning, by the first service provider, 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, Johnson, and Innes further teaches computer-implemented method as described in claim 4 further including determining, the first service provider, that it has permission from a resource owner to access the protected resource hosted by the first service provider prior to issuing a credential to the client application, the credential required for use by the client application to access the protected resource (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, Waters, and Johnson to include a concept of determining, the first service provider, that it has permission from a resource owner to access the protected resource hosted by the first service provider prior to issuing a credential to the client application, the credential required for use by the client application to access the protected resource 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 20180114011 A1: “system and an operating system thereof may employ capabilities to represent, address, and grant access to system objects or resources, such as memory”
US 20240388443 A1: “relate to the field of user authentication, and more specifically, to a browser-based authentication scheme”
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 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
/A.C.L./Primary Examiner, Art Unit 2436
Prosecution Insights