DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 04/02/2024 has been entered.
Response to Arguments
In response to 35 USC 112(a), on page 1 of the remarks filed 04/02/2024, the previous 112 rejection is withdrawn, however there are new issues and therefore the 112 rejection is maintained.
In response to 35 USC 103, on pages 1-4 of the remarks filed 04/02/2024, Applicant argues that Barton2 fails to teach “compiling the second application”.
The Examiner does not concede. Barton2 teaches a “compiling a second application”. Barton2 discloses “The enterprise may use a toolkit to prepare a mobile application as a managed mobile application (block 1002). The toolkit may add functionality (e.g., the MDX framework) that transforms the mobile application into a managed mobile application (block 1004). … The functionality added to the managed mobile application may include functionality that enables the managed mobile application to extract, arrange, and combine the embedded identification tokens in order to construct an application signature [0148][0041]”. The Examiner construes preparing a managed mobile application and adding functionalities thereto as compiling a second application. The Examiner did not solely focus on the “prepare”. As indicated above, Barton discloses using a toolkit to prepare a mobile application as a managed mobile and add functionality (e.g., the MDX framework) that transforms the mobile application into a managed mobile application. Furthermore, applicant indicated that Barton2 application can be compiled for execution as indicated in page 2 of the remarks. Therefore, Barton2 teaches “compiling … a second application”.
In response to 35 USC 103, on pages 1-4 of the remarks filed 04/02/2024, regarding claims 1, 10 and 15 along with their respective dependent claims, Applicant argues that Barton-Barton2-Atwood fails to teach that the server complies the second application in response to receiving a token from the computing device. That the references do not discloses a server generating a cryptographic key by singing a token it received from the computing device, then using that cryptographic key to sign the second application.
The Examiner does not concede. Barton teaches “generating, by the server, a cryptographic key by encrypting the token when the cryptographic key is not represented in a database”. Barton discloses “an encryption key generation feature may be used such that the key used to encrypt data on the device is generated using a passphrase supplied by the user (if offline access is required). It may be XORed with another key randomly generated and stored on the server side if offline access is not required [0096]. An application running in managed mode may encrypt data transmitted from the application [0174]. Furthermore, such information may be created, accessed, modified and/or stored by the access gateway based on one or more risk score [0151]”.By storing to the server then the key was not represented in a database before. Barton shows generating a cryptographic key by encrypting the token.
Atwood teaches “wherein the second application is signed with the cryptographic key”. Atwood discloses “applications may be signed by a developer key [0074]. A message sent to a messaging service with a token identifying a specific application on a specific device can only be received by the application (the application being signed by a specific developer key) running on that device [0075]”. Atwood discloses that the second application is signed by a cryptographic key. A person of ordinary skills in the art would understand that a developer key are cryptographic key. Therefore, the combination of Barton-Barton-Atwood would teach these claim limitations.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Re. claims 1, 10, 15; the claims recite “generating, by the server, a cryptographic key by encrypting the token when the cryptographic key is not represented in a database”. There is no support in the specification that the server generates a cryptographic key by encrypting the token when the cryptographic key is not represented in a database. In paragraph [0113] of the specification recites “As part of generating the key, the server701 may determine whether the key is represented in the database705. As the token and the key may be stored in the database705 such that the database705 may be queried using the key to retrieve the token, having two different tokens stored using the same key may be undesirable and cause unpredictable results. For example, a user may receive the wrong token. As such, generating the key may comprise determining, using the database705, a key that is not represented in the database705. For example, a random key may be generated and/or a key may be received via user input, and the database705 may be queried to determine whether a token is associated with that key. If so, the server701 may cause generation of a new key ”. At most, the specification indicates that the generating a key based on a determination that the key is not represented in the database. Thus, the specification does not have support for the claim limitation “generating, by the server, a cryptographic key by encrypting the token when the cryptographic key is not represented in a database”.
Claims 2, 4-6, 8-9, 11-14, 16-20 and 22 do not cure the deficiencies of Independent claims 1, 10 and 15.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-2, 4-6, 8-9 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Barton et al. (US 20140109171, hereinafter Barton) in view of Barton et al. (US 20140298420, hereinafter Barton2), Atwood et al. (US 20190363886, hereinafter Atwood) and in further view of Bahety (US 20210288808).
Re. claim 1, Barton discloses a method comprising: based on receiving, by a server and from a first application executing on a first portion of a computing device (Fig. 5, a unmanaged partition), a token (Barton discloses the application may, based on the ticket, provide one or more servers of the enterprise with information required to enable the presence-related functionality. Indeed, the application may provide the ticket to a server [0139]. When a user executes a managed application on the mobile device, the user is typically challenged to authenticate the user's identity along with passwords and other factors as dictated by corporate rules [0146]. For example, the enterprise may grant a certificate to a mobile device when applicable policy information allows the device (or application) to access a particular resource that requires a certificate administered by the enterprise [0147]);
generating, by the server, a cryptographic key by encrypting the token when the cryptographic key is not represented in a database (Barton discloses an encryption key generation feature may be used such that the key used to encrypt data on the device is generated using a passphrase supplied by the user (if offline access is required). It may be XORed with another key randomly generated and stored on the server side if offline access is not required [0096]. An application running in managed mode may encrypt data transmitted from the application [0174]. Furthermore, such information may be created, accessed, modified and/or stored by the access gateway based on one or more risk score [0151], by storing to the server then the key was not represented in a database before);
wherein the second portion of the computing device is prevented by a security policy from interacting with the first portion of the computing device (Barton discloses the operating system of the mobile device may be separated into a managed partition 510 and an unmanaged partition 512. Stated differently, by enforcing policies on managed apps, those apps may be restricted to only be able to communicate with other managed apps and trusted enterprise resources, thereby creating a virtual partition that is impenetrable by unmanaged apps and devices [0072]);
and sending, to the second portion of the computing device and in response to the request, the token (Barton discloses At step 1007, the access gateway may transmit a ticket to the mobile device. … As another example, the access gateway may update the listing of applications with an identification of the application that the ticket was issued to [0154]. For example, if the ticket is included in the policy information, the ticket would be transmitted when transmitting the updated policy information [0155]).
Barton does not appear to explicitly disclose storing, in the database, an association between the token and the cryptographic key; compiling, by the server, a second application for execution by the computing device, wherein the compiled second application is configured to, when executed by the computing device, transmit a request, for the token that comprises the cryptographic key, wherein the second application is signed with the cryptographic key; sending, by the server and to a second portion of the computing device, the compiled second application; and receiving, from the compiled second application executing in the second portion of the computing device, the request, for the token, that comprises the cryptographic key; retrieving, from the database and using the cryptographic key, the token.
However, Barton2 teaches compiling by the server, a second application for execution by the computing device (Barton2 teaches The enterprise may use a toolkit to prepare a mobile application as a managed mobile application (block 1002). The toolkit may add functionality (e.g., the MDX framework) that transforms the mobile application into a managed mobile application (block 1004). … The functionality added to the managed mobile application may include functionality that enables the managed mobile application to extract, arrange, and combine the embedded identification tokens in order to construct an application signature [0148] [0041]. The Examiner construes preparing a managed mobile application and adding functionalities thereto as compiling a second application. The claim language “for” is an intended use language); and sending, by the server and to a second portion of the computing device, the compiled second application (Barton2 teaches The enterprise may then publish the managed mobile application to the enterprise application server along with the application metadata and any application policies associated with the mobile application (block 1010). The enterprise application server may receive a request from a mobile device to download a selected mobile application (block 1012). … the enterprise application server may download the selected mobile application to the mobile device in response to receipt of the request (1018) [0149][0041]. Fig. 10, Blocks 1010-1018).
Barton and Barton2 are both considered to be analogous to the claimed invention because they are in the same field of network security. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Barton to incorporate the teachings of Barton2, provide an access manager operating at a mobile device to validate a mobile application installed at the mobile device and prevent or permit access to the computing resource, such that individuals associated with the enterprise may advantageously utilize remote and local computing resources with their personal mobile devices (Barton2; An access manager may operate at a mobile device to validate a mobile application installed at that mobile device. If the access manager does not successfully validate the mobile application, the access manager may prevent the mobile application from accessing computing resource. If the access manager does successfully validate the mobile application, then the access manager may identify the mobile application as a trusted mobile application. The access manager may thus permit the trusted mobile application to access the computing resource [Abstract and paragraphs [0009]-[0014]]).
Further, both of Barton and Barton2 does not appear to explicitly teach: storing, in the database, an association between the token and the cryptographic key; wherein the compiled second application is configured to, when executed by the computing device, transmit a request, for the token that comprises the cryptographic key, wherein the second application is signed with the cryptographic key; and receiving, from the compiled second application executing in the second portion of the computing device, the request, for the token, that comprises the cryptographic key; retrieving, from the database and using the cryptographic key, the token.
However, Atwood teaches wherein the compiled second application is configured to, when executed by the computing device, transmit a request for the token that comprises the cryptographic key (Atwood teaches the client application will cause the client electronic device to send the candidate result to Server A, along with some identifying information such as a token received from Server A or Server B, the application identifier and/or the device identifier, to request a token for the service [0045]. As part of a push request, with the key for decrypting the first nonce forming the payload of the push request. The push request further includes a device identifier (such as a device token) for identifying the client device and the client application as the intended recipient of the message to be pushed by Server B. Server B may then act in response to the push request to forward the key for decrypting the first nonce (which in this embodiment is the second nonce) to the client application [0046][0043][0074][0075], application cause the device to request a token and key with request);
wherein the second application is signed with the cryptographic key (Atwood teaches applications may be signed by a developer key [0074]. Specification application on a specific device [0075]);
and receiving, from the compiled second application executing in the second portion of the computing device, the request, for the token, that comprises the cryptographic key (Atwood teaches the push request further includes a device identifier (such as a device token) for identifying the client device and the client application as the intended recipient of the message to be pushed by Server B. Server B may then act in response to the push request to forward the key for decrypting the first nonce (which in this embodiment is the second nonce) to the client application [0046][0043][0075]).
Barton and Atwood are both considered to be analogous to the claimed invention because they are in the same field of network security. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Barton to incorporate the teachings of Atwood, provide a request for token, the request comprising the cryptographic key; Signing the application with the cryptographic key for the purpose of ensure that the application can continue to access data (Atwood; ensures that only the application or an authorized updated version of the application can continue to access data [0074]).
Further, the combination of Barton-Barton2-Atwood does not appear to explicitly teach: storing, in the database, an association between the token and the cryptographic key; retrieving, from the database and using the cryptographic key, the token.
However, Bahety teaches storing, in the database, an association between the token and the cryptographic key (Bahety teaches the server will store the received public key and link it to the access tokens issued to the client [0038]); retrieving, from the database and using the cryptographic key, the token (Bahety teaches utilizing key to securely refresh access tokens [0036]. Store the received public key and link it to the access tokens issued to the client [0038]. The client will use the private key for the access token [0039]).
Barton and Atwood are both considered to be analogous to the claimed invention because they are in the same field of network security. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Barton to incorporate the teachings of Bahety, storing token and keys, using the key for the token for the purpose of improving security and storing securely (Bahety; refresh tokens be stored securely by a client application because they permit a user or client application to remain authenticated as long as the refresh token remains valid [0032]. Issuing refresh tokens that can provide improved security involving Application Program interfaces [0036]).
Re. claim 2, the combination of Barton-Barton2-Atwood-Bahety teach the method of claim 1, wherein the compiled second application comprises an authentication application (Atwood teaches applications may be signed by a developer key. This ensures that only the application or an authorized updated version of the application can continue to access data [0074]. First application as having been authenticated [0017]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Barton to incorporate the teachings of Atwood, wherein the compiled second application comprises an authentication application for the purpose of ensure that the application can continue to access data (Atwood; ensures that only the application or an authorized updated version of the application can continue to access data [0074]).
Re. claim 4, the combination of Barton-Barton2-Atwood-Bahety teach the method of claim 1, wherein sending the compiled second application comprises: sending, to a mobile device management application configured to manage the second portion of the computing device, the compiled second application (Barton2 teaches Once the mobile device is enrolled, the MDM system may leverage the managed relationship to enforce policies, monitor the mobile device, push information to the mobile device, and the like [0167]. It will be appreciated that the MDM system may additionally leverage the managed relationship to push mobile applications to the managed mobile device in order to control which mobile applications are installed at the mobile device [0171]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Barton to incorporate the teachings of Barton2, provide an access manager operating at a mobile device to validate a mobile application installed at the mobile device and prevent or permit access to the computing resource, such that individuals associated with the enterprise may advantageously utilize remote and local computing resources with their personal mobile devices (Barton2; An access manager may operate at a mobile device to validate a mobile application installed at that mobile device. If the access manager does not successfully validate the mobile application, the access manager may prevent the mobile application from accessing computing resource. If the access manager does successfully validate the mobile application, then the access manager may identify the mobile application as a trusted mobile application. The access manager may thus permit the trusted mobile application to access the computing resource [Abstract and paragraphs [0009]-[0014]]).
Re. claim 5, the combination of Barton-Barton2-Atwood-Bahety teach the method of claim 1, wherein sending the compiled second application comprises: sending, to the second portion of the computing device, a Uniform Resource Locator (URL) which, when accessed by a web browser executing in the second portion of the computing device, provides the compiled second application (Barton2 teaches the access manager may provide the user with an interface from which to browse the enterprise application server (e.g., the enterprise application store) and select various managed mobile applications to download to the mobile device. … In this way, the managed mobile applications presented to the user as available to download depend upon the rights and entitlements assigned to the user, e.g., the enterprise application server may only present managed mobile applications that the user is entitled to use [0144]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Barton to incorporate the teachings of Barton2, provide an access manager operating at a mobile device to validate a mobile application installed at the mobile device and prevent or permit access to the computing resource, such that individuals associated with the enterprise may advantageously utilize remote and local computing resources with their personal mobile devices (Barton2; An access manager may operate at a mobile device to validate a mobile application installed at that mobile device. If the access manager does not successfully validate the mobile application, the access manager may prevent the mobile application from accessing computing resource. If the access manager does successfully validate the mobile application, then the access manager may identify the mobile application as a trusted mobile application. The access manager may thus permit the trusted mobile application to access the computing resource [Abstract and paragraphs [0009]-[0014]]).
Re. claim 6, the combination of Barton-Barton2-Atwood-Bahety teach the method of claim 1, wherein generating the key comprises: receiving, from the computing device, user input comprising at least a portion of the cryptographic key (Barton discloses an encryption key generation feature may be used such that the key used to encrypt data on the device is generated using a passphrase supplied by the user. It may be XORed with another key randomly generated and stored on the server side [0099]).
Re. claim 8, the combination of Barton-Barton2-Atwood-Bahety teach the method of claim 1, wherein storing the association comprises: configuring the database to delete the token after a predetermined time period (Barton discloses For example, an access gateway may receive a selective wipe acknowledgment that includes a listing of application and/or listing of tickets that were affected/deleted by the selective wipe and, respectively, may update its listing of applications installed on the mobile device by removing entries corresponding to the application(s) indicated by the acknowledgement and/or update its listing of tickets issued and valid to the mobile device by removing entries corresponding to the tickets indicated by the acknowledgement [0166][0080][0099][0125]).
Re. claim 9, the combination of Barton-Barton2-Atwood-Bahety teach the method of claim 1, wherein retrieving the token comprises: querying, using the cryptographic key and a user identifier associated with the computing device, the database for the token (Bahety teaches utilizing key to securely refresh access tokens [0036]. Store the received public key and link it to the access tokens issued to the client [0038]. The client will use the private key for the access token [0039]).
Re. claims 18, the combination of Barton-Barton2-Atwood teach the method of claim 15,
deleting the token and the key after a predetermined time period (Barton discloses an access gateway may receive a selective wipe acknowledgment that includes a listing of application and/or listing of tickets that were affected/deleted by the selective wipe and, respectively, may update its listing of applications installed on the mobile device by removing entries corresponding to the application(s) indicated by the acknowledgement and/or update its listing of tickets issued and valid to the mobile device by removing entries corresponding to the tickets indicated by the acknowledgement [0166][0080][0099][0125]).
Barton-Barton2 do not appear to explicitly teach storing the token and the cryptographic key.
However, Bahety teaches storing the token and the key(Bahety teaches the server will store the received public key and link it to the access tokens issued to the client [0038]).
Barton and Bahety are both considered to be analogous to the claimed invention because they are in the same field of network security. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Barton-Barton2 to incorporate the teachings of Bahety, storing token and keys, using the key for the token for the purpose of improving security and storing securely (Bahety; refresh tokens be stored securely by a client application because they permit a user or client application to remain authenticated as long as the refresh token remains valid [0032]. Issuing refresh tokens that can provide improved security involving Application Program interfaces [0036]).
Claims 10-17, 19 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Barton et al. (US 20140109171, hereinafter Barton) in view of Barton et al. (US 20140298420, hereinafter Barton2), and in further view of Atwood et al. (US 20190363886, hereinafter Atwood).
Re. claim 10, Barton discloses a method comprising: sending, to a server and from a first application executing on a first portion of a computing device (Fig. 5, a unmanaged partition), a token (Barton discloses when a user executes a managed application on the mobile device, the user is typically challenged to authenticate the user's identity along with passwords and other factors as dictated by corporate rules) [0146]. For example, the enterprise may grant a certificate to a mobile device when applicable policy information allows the device (or application) to access a particular resource that requires a certificate administered by the enterprise [0147]); wherein the second portion of the computing device is prevented by a security policy from interacting with the first portion of the computing device (Barton teaches the operating system of the mobile device may be separated into a managed partition 510 and an unmanaged partition 512. Stated differently, by enforcing policies on managed apps, those apps may be restricted to only be able to communicate with other managed apps and trusted enterprise resources, thereby creating a virtual partition that is impenetrable by unmanaged apps and devices [0072]); receiving, from the server and in the second portion of the computing device , the token (Barton discloses At step 1007, the access gateway may transmit a ticket to the mobile device. … As another example, the access gateway may update the listing of applications with an identification of the application that the ticket was issued to [0154]. For example, if the ticket is included in the policy information, the ticket would be transmitted when transmitting the updated policy information [0155]); that comprises a cryptographic key, wherein the key is generated by encrypting the token when the cryptographic key is not represented in a database (Barton discloses an encryption key generation feature may be used such that the key used to encrypt data on the device is generated using a passphrase supplied by the user (if offline access is required). It may be XORed with another key randomly generated and stored on the server side if offline access is not required [0096]. An application running in managed mode may encrypt data transmitted from the application [0174]); and decrypting, using the cryptographic key, the token (Barton discloses prevent an attacker from decrypting any data even with a stolen encryption key [0097]. In addition, the data communicated from the computing device to the application may also be encrypted, and the application running in managed mode may be configured to decrypt the received data [0190]).
Barton does not appear to explicitly disclose receiving, in a second portion of a computing device and in response to sending the token, a second application that, when executed by the computing device, is configured to transmit a request, for the token, that comprises a key; and sending, to the server, a request by executing, in the second portion of the computing device, the second application; wherein the second application is compiled by the server and signed with the cryptographic key in response to the server receiving the token.
However, Barton2 teaches receiving, in a second portion of a computing device and in response to sending the token, a second application that (Barton2 teaches the enterprise may then publish the managed mobile application to the enterprise application server along with the application metadata and any application policies associated with the mobile application (block 1010). The enterprise application server may receive a request from a mobile device to download a selected mobile application (block 1012). … the enterprise application server may download the selected mobile application to the mobile device in response to receipt of the request (1018) [0149]. Fig. 10, Blocks 1010-1018); wherein the second application is compiled by the server (Barton2 teaches The enterprise may use a toolkit to prepare a mobile application as a managed mobile application (block 1002). The toolkit may add functionality (e.g., the MDX framework) that transforms the mobile application into a managed mobile application (block 1004). … The functionality added to the managed mobile application may include functionality that enables the managed mobile application to extract, arrange, and combine the embedded identification tokens in order to construct an application signature [0148] [0041]. The Examiner construes preparing a managed mobile application and adding functionalities thereto as compiling a second application).
Barton and Barton2 are both considered to be analogous to the claimed invention because they are in the same field of network security. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Barton to incorporate the teachings of Barton2, provide an access manager operating at a mobile device to validate a mobile application installed at the mobile device and prevent or permit access to the computing resource, such that individuals associated with the enterprise may advantageously utilize remote and local computing resources with their personal mobile devices (Barton2 An access manager may operate at a mobile device to validate a mobile application installed at that mobile device. If the access manager does not successfully validate the mobile application, the access manager may prevent the mobile application from accessing computing resource. If the access manager does successfully validate the mobile application, then the access manager may identify the mobile application as a trusted mobile application. The access manager may thus permit the trusted mobile application to access the computing resource [Abstract and paragraphs [0009]-[0014]]).
Further, both of Barton and Bartion2 does not appear to explicitly teach when executed by the computing device, is configured to transmit a request, for the token, that comprises a cryptographic key; and sending, to the server, a request by executing, in the second portion of the computing device, the second application; and signed with the cryptographic key in response to the server receiving the token.
However, Atwood teaches when executed by the computing device, is configured to transmit a request, for the token that comprises a cryptographic key (Atwood teaches the client application will cause the client electronic device to send the candidate result to Server A, along with some identifying information such as a token received from Server A or Server B, the application identifier and/or the device identifier, to request a token for the service [0045]. As part of a push request, with the key for decrypting the first nonce forming the payload of the push request. The push request further includes a device identifier (such as a device token) for identifying the client device and the client application as the intended recipient of the message to be pushed by Server B. Server B may then act in response to the push request to forward the key for decrypting the first nonce (which in this embodiment is the second nonce) to the client application [0046][0043], application cause the device to request a token and key with request);
signed with the cryptographic key in response to the server receiving the token (Atwood teaches applications may be signed by a developer key [0074]. A message sent to a messaging service with a token identifying a specific application on a specific device can only be received by the application (the application being signed by a specific developer key) running on that device [0075]);
and sending, to the server, the request by executing, in the second portion of the computing device, the second application (Atwood teaches the push request further includes a device identifier (such as a device token) for identifying the client device and the client application as the intended recipient of the message to be pushed by Server B. Server B may then act in response to the push request to forward the key for decrypting the first nonce (which in this embodiment is the second nonce) to the client application [0046][0043][0075]).
Barton and Courage are both considered to be analogous to the claimed invention because they are in the same field of network security. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Barton to incorporate the teachings of Atwood, provide a request for token, the request comprising a cryptographic key; Signing the application with a key for the purpose of ensure that the application can continue to access data (Atwood; ensures that only the application or an authorized updated version of the application can continue to access data [0074]).
Re. claim 11, the combination of Barton-Barton2-Atwood teach the method of claim 10, wherein the second application comprises an authentication application (Atwood teaches applications may be signed by a developer key. This ensures that only the application or an authorized updated version of the application can continue to access data [0074]. First application as having been authenticated [0017]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Barton to incorporate the teachings of Atwood, wherein the compiled second application comprises an authentication application for the purpose of ensure that the application can continue to access data (Atwood; ensures that only the application or an authorized updated version of the application can continue to access data [0074]).
Re. claim 12, the combination of Barton-Barton2-Atwood teach the method of claim 10, wherein sending the request for the token comprises: receiving, via the second application, user input comprising at least a portion of the cryptographic key (Barton discloses an encryption key generation feature may be used such that the key used to encrypt data on the device is generated using a passphrase supplied by the user. It may be XORed with another key randomly generated and stored on the server side [0096]).
Re. claim 13, the combination of Barton-Barton2-Atwood teach the method of claim 10, further comprising: encrypting the token before sending the token to the server (Barton discloses For example, an application running in managed mode may be communicating with a computing device over a network, and the data transmitted from the application to the device may be encrypted [0174]).
Re. claim 14, the combination of Barton-Barton2-Atwood teach the method of claim 10, further comprising: storing, on storage of the computing device, the token (Barton discloses For example, the technician may view the listing of application or listing of tickets via the user interface, modify the listing via the user interface, create a ticket to be sent to a mobile device via the user interface, and cause the access gateway to store and/or send the ticket to the mobile device via the user interface [0157]); and deleting, after receiving the cryptographic key, the token from the storage of the computing device (Barton discloses Steps 1103-1109 form part of a process for performing the selective wipe. Other data may be deleted from the mobile device during the selective wipe process. The below steps are related to identifying and deleting tickets from secure containers as part of a selective wipe process that deletes or otherwise makes inaccessible enterprise data associated with the managed application, which may include the policy information [0162]. Other types of encryption may be used, and other levels and types of security measures may be applied based on a desired level and/or type of security, as well as different key recovery features. In an embodiment, an application running in managed mode may save, modify or delete data in secure data container 528. The data saved or modified may be encrypted similar to other data stored in secure data container [0185]).
Re. claim 15, Barton discloses a method comprising: based on receiving, by a server and from a first application executing on a first portion of a computing device, a token (Barton discloses when a user executes a managed application on the mobile device, the user is typically challenged to authenticate the user's identity along with passwords and other factors as dictated by corporate rules. After authentication, the mobile device may be provided with a policy for determining how the managed application is to perform network accesses [0146]); wherein the key is generated by encrypting the token (Barton discloses an encryption key generation feature may be used such that the key used to encrypt data on the device is generated using a passphrase supplied by the user (if offline access is required). It may be XORed with another key randomly generated and stored on the server side if offline access is not required [0096]. An application running in managed mode may encrypt data transmitted from the application [0174]); causing, a second portion of the computing device to execute the second application, wherein the second portion of the computing device is prevented by a security policy from interacting with the first portion of the computing device (Barton discloses the secure applications may be secure native applications 514, secure remote applications 522 executed by a secure application launcher 518, virtualization applications 526 executed by a secure application launcher 518, and the like. The secure native applications 514 may be wrapped by a secure application wrapper 520. The secure application wrapper 520 may include integrated policies that are executed on the mobile device 502 when the secure native application is executed on the device [0073]. The operating system of the mobile device may be separated into a managed partition 510 and an unmanaged partition 512. Stated differently, by enforcing policies on managed apps, those apps may be restricted to only be able to communicate with other managed apps and trusted enterprise resources, thereby creating a virtual partition that is impenetrable by unmanaged apps and devices [0072]); sending, by the server and to the second portion of the computing device, and in response to the request, the token (Barton discloses At step 1007, the access gateway may transmit a ticket to the mobile device. … As another example, the access gateway may update the listing of applications with an identification of the application that the ticket was issued to [0154]. For example, if the ticket is included in the policy information, the ticket would be transmitted when transmitting the updated policy information [0155]).
Barton does not appear to explicitly teach compiling, by the server, a second application for execution by the computing device; signing, by the server, a second application with a cryptographic key corresponding to the token; wherein the second application is configured to, when executed by the computing device, transmit a request, for the token that comprises the cryptographic key; and receiving, from the second application, the request, for the token, that comprises the cryptographic key.
However, Barton2 teaches compiling, by the server, a second application for execution by the computing device (Barton2 teaches The enterprise may use a toolkit to prepare a mobile application as a managed mobile application (block 1002). The toolkit may add functionality (e.g., the MDX framework) that transforms the mobile application into a managed mobile application (block 1004). … The functionality added to the managed mobile application may include functionality that enables the managed mobile application to extract, arrange, and combine the embedded identification tokens in order to construct an application signature [0148] [0041]. The Examiner construes preparing a managed mobile application and adding functionalities thereto as compiling a second application).
Barton and Barton2 are both considered to be analogous to the claimed invention because they are in the same field of network security. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Barton to incorporate the teachings of Barton2, provide an access manager operating at a mobile device to validate a mobile application installed at the mobile device and prevent or permit access to the computing resource, such that individuals associated with the enterprise may advantageously utilize remote and local computing resources with their personal mobile devices (Barton2 An access manager may operate at a mobile device to validate a mobile application installed at that mobile device. If the access manager does not successfully validate the mobile application, the access manager may prevent the mobile application from accessing computing resource. If the access manager does successfully validate the mobile application, then the access manager may identify the mobile application as a trusted mobile application. The access manager may thus permit the trusted mobile application to access the computing resource [Abstract and paragraphs [0009]-[0014]]).
However, Atwood teaches wherein the second application is configured to, when executed by the computing device, transmit a request, for the token that comprises the cryptographic key (Atwood teaches the client application will cause the client electronic device to send the candidate result to Server A, along with some identifying information such as a token received from Server A or Server B, the application identifier and/or the device identifier, to request a token for the service [0045]. As part of a push request, with the key for decrypting the first nonce forming the payload of the push request. The push request further includes a device identifier (such as a device token) for identifying the client device and the client application as the intended recipient of the message to be pushed by Server B. Server B may then act in response to the push request to forward the key for decrypting the first nonce (which in this embodiment is the second nonce) to the client application [0046][0043], application cause the device to request a token and key with request);
signing, by the server (Atwood discloses server [0075]), the second application with a cryptographic key corresponding to the token (Atwood teaches applications may be signed by a developer key [0074]. Applications can retrieve a device token. Specification application on a specific device [0075]);
and receiving, by the server from the second application, the request, for the token, that comprises the cryptographic key (Atwood teaches the push request further includes a device identifier (such as a device token) for identifying the client device and the client application as the intended recipient of the message to be pushed by Server B. Server B may then act in response to the push request to forward the key for decrypting the first nonce (which in this embodiment is the second nonce) to the client application [0046][0043][0075]).
Barton and Atwood are both considered to be analogous to the claimed invention because they are in the same field of network security. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Barton to incorporate the teachings of Atwood, provide a request for token, the request comprising a cryptographic key; Signing the application with a key for the purpose of ensure that the application can continue to access data (Atwood; ensures that only the application or an authorized updated version of the application can continue to access data [0074]).
Re. claims 16, the combination of Barton-Barton2-Atwood teach the method of claim 15, wherein the second application comprises an authentication application (Atwood teaches applications may be signed by a developer key. This ensures that only the application or an authorized updated version of the application can continue to access data [0074]. First application as having been authenticated [0017]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Barton-Barton2 to incorporate the teachings of Atwood, wherein the compiled second application comprises an authentication application for the purpose of ensure that the application can continue to access data (Atwood; ensures that only the application or an authorized updated version of the application can continue to access data [0074]).
Re. claims 17, the combination of Barton-Barton2-Atwood teach the method of claim 15, Barton does not explicitly teach but Barton2 teaches wherein causing the second portion of the computing device to execute the second application comprises: sending, to a mobile device management application configured to manage the second portion of the computing device, the second application (Barton2 teaches Once the mobile device is enrolled, the MDM system may leverage the managed relationship to enforce policies, monitor the mobile device, push information to the mobile device, and the like [0166]. It will be appreciated that the MDM system may additionally leverage the managed relationship to push mobile applications to the managed mobile device in order to control which mobile applications are installed at the mobile device [0171]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Barton to incorporate the teachings of Barton2, provide an access manager operating at a mobile device to validate a mobile application installed at the mobile device and prevent or permit access to the computing resource, such that individuals associated with the enterprise may advantageously utilize remote and local computing resources with their personal mobile devices (Barton2 An access manager may operate at a mobile device to validate a mobile application installed at that mobile device. If the access manager does not successfully validate the mobile application, the access manager may prevent the mobile application from accessing computing resource. If the access manager does successfully validate the mobile application, then the access manager may identify the mobile application as a trusted mobile application. The access manager may thus permit the trusted mobile application to access the computing resource [Abstract and paragraphs [0009]-[0014]]).
Re. claims 19, the combination of Barton-Barton2-Atwood teach the method of claim 15, further comprising: receiving, from the computing device, user input comprising at least a portion of the cryptographic key (Barton discloses an encryption key generation feature may be used such that the key used to encrypt data on the device is generated using a passphrase supplied by the user. It may be XORed with another key randomly generated and stored on the server side [0096]).
Re. claims 20, the combination of Barton-Barton2-Atwood teach the method of claim 15,
Barton, Barton2 do not explicitly teach generating, after receiving the token, the cryptographic key.
However, Atwood teaches generating, after receiving the token, the cryptographic key (Atwood teaches the client application will cause the client electronic device to send the candidate result to Server A, along with some identifying information such as a token received from Server A or Server B, the application identifier and/or the device identifier, to request a token for the service [0045]. As part of a push request, with the key for decrypting the first nonce forming the payload of the push request. The push request further includes a device identifier (such as a device token) for identifying the client device and the client application as the intended recipient of the message to be pushed by Server B. Server B may then act in response to the push request to forward the key for decrypting the first nonce (which in this embodiment is the second nonce) to the client application [0046][0043][0074][0075]).
Barton and Atwood are both considered to be analogous to the claimed invention because they are in the same field of network security. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Barton to incorporate the teachings of Atwood, generating, after receiving the token, the cryptographic key for the purpose of ensure that the application can continue to access data (Atwood; ensures that only the application or an authorized updated version of the application can continue to access data [0074]).
Claim 22 is rejected under 35 U.S.C. 103 as being unpatentable over Barton et al. (US 20140109171, hereinafter Barton) in view of Barton et al. (US 20140298420, hereinafter Barton2), Atwood et al. (US 20190363886, hereinafter Atwood), in view of Bahety (US 20210288808) and in further view of Helms et al. (US 20160105788, hereinafter as Helms).
Re. claims 22, the combination of Barton-Barton2-Atwood-Bahety teach the method of claim 1, the combination of Barton-Barton2-Atwood-Bahety do not explicitly teach but Helms teach wherein the storing, in the database, comprises storing an association between the token and a Media Access Control (MAC) address of the computing device (Helms teaches the download/application server 570 acquires wireless station information, including its MAC address and a unique token, and user information and stores the station and user information in a datastore 572 [0063], storing MAC and token in the database).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of Barton to incorporate the teachings of Helms, provide a MAC address in order to uniquely identify a certain device (Helms [Col 9 line 60 – Col 10 line 35]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Pizot et al. (US 20210184854) discloses tokens involve cryptographic keys as the device signatures, the Mode 0 tokens ensure that the identity of the electronic device 100 is not compromised and a secure communication may be established between the electronic device 100 and the user device.
Kulkarni (US 9226143) discloses (a) providing a set of keys, each key corresponding to one of the predetermined functions, (b) receiving an application from an application provider together with information identifying a set of needed functions, (c) generating a signed application by signing the received application with each of the keys that correspond to one of the needed functions identified by the received information, and (d) transmitting information identifying the needed functions and the signed application and a set of access rules to a Secure Element of the mobile device.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KEVIN A AYALA whose telephone number is (571)270-3912. The examiner can normally be reached Monday-Thursday 8AM-5PM; Friday:Variable EST.
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, Jorge Ortiz-Criado can be reached at 571-272-7624. 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.
/KEVIN AYALA/Primary Examiner, Art Unit 2496