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 .
Response to Arguments
In response to 35 USC 112(a), on page 1 of the remarks filed 05/05/2026, the 35 USC 112(a) has been withdrawn in light of claim amendment.
In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., the first and second portions of the computing device are separated by a security wall and cannot directly interact) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). The combined prior arts shows the device partitioning or the relaying of a token between segregated software environments. The Examiner did not assemble a “mosaic” of features to solve a problem. Examiner has shown how the prior arts of Barton, Barton2, Atwood and Bahety disclose the invention of independent claims 1, 10 and 15.
A mere statement or argument that the Office has not established a prima facie case of obviousness or that the Office’s reliance on common knowledge is unsupported by documentary evidence will not be considered substantively adequate to rebut the rejection or an effective traverse of the rejection under 37 CFR 1.111(b). Office personnel addressing this situation may repeat the rejection made in the prior Office action and make the next Office action final. See MPEP § 706.07(a).
In response to applicant's argument that the examiner's conclusion of obviousness is based upon improper hindsight reasoning, it must be recognized that any judgment on obviousness is in a sense necessarily a reconstruction based upon hindsight reasoning. But so long as it takes into account only knowledge which was within the level of ordinary skill at the time the claimed invention was made, and does not include knowledge gleaned only from the applicant's disclosure, such a reconstruction is proper. See In re McLaughlin, 443 F.2d 1392, 170 USPQ 209 (CCPA 1971).
It has been held that a prior art reference must either be in the field of the inventor’s endeavor or, if not, then be reasonably pertinent to the particular problem with which the inventor was concerned, in order to be relied upon as a basis for rejection of the claimed invention. See In re Oetiker, 977 F.2d 1443, 24 USPQ2d 1443 (Fed. Cir. 1992). In this case, Barton, Barton2, Atwood and Bahety are all in the same field of endeavor.
In response to applicant’s argument that there is no teaching, suggestion, or motivation to combine the references, the examiner recognizes that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007). In this case, the Examiner has shown reasons to combine the teachings of the reference. Please see 35 USC 103 rejection.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-2, 4-6, 8-9 and 22 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 recites the limitation "computing device" in line 8. There is insufficient antecedent basis for this limitation in the claim.
Claims 2, 4-6, 8-9 and 22 fall together accordingly as they do cure the deficiencies of claim 1.
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 (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]);
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 and within a second portion of 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 the 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; when executed within the second portion of 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 within 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 within the second portion of 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 within 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 (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.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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
Prosecution Insights