DETAILED ACTION
The present application 18/117,209 titled, SYSTEM AND METHOD FOR SECURE APPROVAL OF OPERATIONS REQUESTED BY A DEVICE MANAGEMENT SYSTEM, with claims 1-9 and 11-24 with an effective filing date of 03/03/2023. The claims are drawn to a system, an apparatus, and a method for managing secure device operations are 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 4/06/2026 has been entered.
This action is in response to the claims and remarks filed 4/06/2026. Claims 1-9 and 11-24 are pending. Claims 1 (a machine), 14 (a method), and 21 (a machine) are independent.
Response to Arguments
Applicant’s arguments, see first paragraph of page 10, filed 4/06/2026, with respect to the rejection(s) of claim(s) 14 and 21 under Stern (US 9819661 B2 filed: 09/12/2013), in view of Takagi et al. (US 2020/0186533 A1 filed: 12/04/2019) have been fully considered and are persuasive. Stern in view of Takagi does not disclose “an authorized user associated with the system user to review the operation request and authorize or reject the operation request”. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in further view of Peuhkurinen et al. (US 2019/0236312 filed 2016).
Applicant's arguments filed 4/06/2026 have been fully considered but they are not persuasive.
On page 9 of the remarks, Applicant states: “the authorization server 304 of Stern is external to the mobile communication device 10, as taught for example at FIG. 6 of Stern.
In contrast, the signatory module of the presently claimed invention is located on premises of a system user, and the signatory module authorizes operations before the management module transmits an authorized operation request to the managed device.” This argument is not persuasive.
As disclosed in Applicant’s specification ¶¶ 26 and 29, the premises of a system user is a corporate network. In other words, a discrete network rather than a physical building. Takagi Figure 1 discloses that the elements of a system may be interconnected via a LAN, a local area network, which is a discrete network.
Further Stern discloses an authorization prior to transmitting the “authorized operation request” as seen in col. 13 lines 24-31. In col. 13 Stern describes that the device manager receives the authorization responses and determines whether the token authorizes the request, before transmitting the response to the communication device.
As to the various bolded elements in Applicant’s arguments on pages 9 and 10 of the remarks, see the updated citations.
On page 10 of the remarks, Applicant states:
“Applicant asserts that, in contrast to Stern and Takagi, taken alone or in combination, the claimed invention pertains to an on-premises authorization architecture in which the customer or user, through an on-premises signatory module with their own PKI environment, can maintain control over operations requested by a cloud-based management system. As the secure signature infrastructure, for example a PKI environment, is managed by the system user, the system user can remain in control of the authorization of an operation that is requested using this system. This feature can provide a level of certainty that there are no third-party issues that may arise from operations being inadvertently requested by a provider or manufacturer of the system, as taught for example at paragraph [0042] of the specification as originally filed.”
This argument is not persuasive as it is premised on unclaimed subject matter.
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., “through an on-premises signatory module with their own PKI environment, can maintain control over operations requested by a cloud-based management system.”) 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).
Nothing in the claims requires separate control or possession of the elements of the claim. There is no requirement for an external cloud environment, nor is the management module required to be separate from the “premises”. The claim as worded appears to require the management module to be proximate to the other elements of the claim as it delegates signatures to “a local authorization device”, such as a smart card (Applicant’s specification ¶ 37); delegation to a smart suggests that the management module is in physical contact with the smart card.
The asserted novelty of Applicant’s specification ¶ 42 is not required or implied by the claims as presently presented.
Applicant’s further remarks are not persuasive at least for the reasons discussed above.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
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-9 and 11-13 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 requires: “the management module configured to require authorization of operations by the signatory module prior to transmitting an authorized operation request to the managed device”
Claim 1 also requires: “the signatory module configured to … generate [[an]]the authorized operation request”
Claim 1 further requires: “upon receipt and verification of the authorized operation request by the managed device”
The claim is phrased ambiguously such that no particular device is require to transmit the “authorized operation request” yet conditions on its transmittal are dictated.
In other word, it is ambiguous to recite conditions for a hypothetical event that is not required by the claim.
Claims 2-9 and 11-13 are rejected due to their dependency on claim 1.
Claim Term Interpretation
“on premises” is interpreted to mean within a corporate network, as opposed to the internet. Typically the term premises is used to denote a household of a subscriber. However, in the corporate setting (Applicant’s specification ¶¶ 26 and 29) networks are not constrained to physical buildings and are typically linked together as a corporate LAN. Therefore, Examiner interprets on premises to mean within the logical corporate network (such as a LAN) rather than within a particular residence.
CLAIM INTERPRETATION
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “management module configured to” on line 4 and “the signatory module configured to” on line 6 in claim 1.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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.
Claim(s) 1-2, 4, 6-7, 9, 12-13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Stern (US 9819661 B2 filed: 09/12/2013), in view of Takagi et al. (US 2020/0186533 A1 filed: 12/04/2019).
Regarding claim 1, Stern teaches the system for device management and authorization.
Stern teaches:
A system for secure approval of an operation requested by a device management system, the system comprising:
(mobile device 10 of Fig. 1) a managed device having information indicative of an authorization key (Col. 4 line 61 – Col. 5 line 8 discloses a device with secure element 64 used as a keystore for PKI, encryption keys and passwords.), the information indicative of the authorization key is associated with a public key infrastructure (PKI) environment; (Col. 12 line 24 – Col. 13 line 49 and Col. 17 lines 4-15 disclose a PKI environment for communication between device, manager, and authentication server.), wherein the managed device is provisioned with the information indicative of the authorization key by a system user; (Col. 9 line 40 – col. 9 line 51 discloses “the security policy of first persona 110 may only be configured by a first persona owner, and the security policy of second persona 120 may only be configured by a second persona owner. More specifically, each security policy may be signed by the private key of the persona owner and the signature may be validated by mobile communication device 10 using a corresponding public key of the persona owner before security supervisor 108 applies to security policy to the associated persona.” This is discussing Fig. 3, which is the hardware of the mobile communication device 10)
(device manager 302 of Fig. 1) a management module configured to manage operations performed by the managed device, the management module configured to communicate with a signatory module; (Col. 12 line 24 – Col 13 line 49, Fig. 6 “Authorization server 304 receives the request from DM 302 and verifies the signature of DM 302”), the management module configured to require authorization of operations by the signatory module prior to transmitting an authorized operation request to the managed device (Col. 12 line 24 – Col 13 line 49, Fig. 6 “device manager (DM) 302, may generate and transmit a request to an authorization server … Moreover, the request is signed by a first private key of a private, public key pair assigned to an administrator.” After the generation of the request to the auth server: col. 13 lines 24-31 “DM 302 receives the authorization response and determines whether the authorization token authorizes the requested operation. … DM 302 then transmits the authorization response file to mobile communication device 10”)
(authorization server 304 of Fig. 1) the signatory module configured to receive an operation request associated with the operation, the signatory module further configured to enable authorization of the operation request through the association of the authorization key with the operation request and generate the authorized operation request, (Col. 12 line 24 – Col. 13 line 49 discloses an authorization server that after receive the request will verify the signature and determine operation parameters align with policies. The authorization server will then generate a response that includes: the initial request, an authorization token and signature by the server.) wherein elements of the signatory module are remote to the management module (authorization server 304 of Fig. 1 distinct from device manager 302 of Fig. 1), and
the PKI environment is provided and controlled by the system user (Col. 4 line 61 – Col. 5 line 8) independently of the management module; (device manager 302 of Fig. 1)
upon receipt and verification of the authorized operation request by the managed device, the managed device is responsive to the authorized operation request. (Col. 12 line 24 – Col 13 line 49 disclose that the device will be responsive to the authorization response if all signatures are valid.)
Stern does not explicitly disclose:
wherein the signatory module is located on premises of the system user and
…
The management module configured to delegate a signature operation to a local authorization device integrated with the PKI environment, and the local authorization device configured to store or hold the authorization key;
Takagi discloses:
wherein the signatory module is located on premises of the system user and (“The terminal device 100 and the providing server 200 are, the terminal device 100 and the authentication server 300 are, and the providing server 200 and the authentication server 300 are communicably coupled to each other via a network N. As the network N, any type of communication network such as a local area network (LAN) ” ¶ 34)
…
The management module configured to delegate a signature operation to a local authorization device integrated with the PKI environment, (“the signature request unit 282 notifies the signature unit 44 of the external authenticator 400 of the process name and the front display application information. When the process name with the signature and the front display application information with the signature, which are signed in the signature unit 44, are received, the signature request unit 282 transmits the received information to the server verification cooperation unit 242.” Takagi ¶ 52) and the local authorization device configured to store or hold the authorization key; (“The key management unit 42 manages the private key. The key management unit 42 may, as the private key, separately manage a private key used for the above-described authentication processing (FIG. 2)” Takagi ¶ 41. “As illustrated in FIG. 2, in the authentication system 10, (1) the external authenticator 400 generates a new key pair (public key, private key) at the time of registration to an online service, the private key is held by the external authenticator 400, and the public key is registered in the authentication server 300 in advance.” Takagi ¶ 36. Public key transferred via the “terminal device” the claimed management application. See also Takagi ¶ 48 describing ID correlations between authenticator and client application on terminal)
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Stern with Takagi by providing the external authenticator of Takagi to perform signature operations (e.g. Takagi Fig. 2) and integrating the elements of the system together in a LAN rather than over the internet (Takagi Fig. 1). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Stern with Takagi in order to perform multi-factor-authentication using an external token, thereby increasing security of the authentication and signature.
Regarding claim 2, Stern in view of Takagi further teaches the system of claim 1 as detailed above.
Stern further teaches:
The system according to claim 1, wherein the authorized operation request includes information indicative of the operation request and a proof of authorization. (Col. 12 line 24 – Col. 13 line 49 disclose the authorized operation request includes: the initial request, an authorization token and signature by the server. The initial request includes: identification of device, the operation to be performed, time period, and location.)
Regarding claim 4, Stern in view of Takagi further teaches the system of claim 1 as detailed above.
Stern further teaches:
The system according to claim 1, wherein communication between at least some of the managed device, management module and signatory module is performed using a cellular communication network. (Fig. 6 and Col. 12 line 24 – Col. 13 line 49 disclose a mobile device 10 in communication with an administrative computer, device manager 302. The device manager 302 communicates with the authorization server 304. These communications would require cellular communication between the mobile device, the device manager and the authorization server.)
Regarding claim 6, Stern in view of Takagi further teaches the system of claim 2 as detailed above.
Stern further teaches:
The system according to claim 2, wherein verification of the proof of authorization is performed by the managed device using the information indicative of the authorization key. (Col. 13 lines 35-49 disclose when the mobile device receives the authorization response it will verify the signatures with its private key. The response can also include a certificate chain to an authorization root of trust for additional proof of authorization.)
Regarding claim 7, Stern in view of Takagi further teaches the system of claim 2 as detailed above.
Stern further teaches:
The system according to claim 2, wherein verification of the proof of authorization is performed at least in part using a certificate chain. (Col. 13 lines 35-49 disclose when the mobile device receives the authorization response the signatures with its private key. The response can also include a certificate chain to an authorization root of trust for additional proof of authorization.)
Regarding claim 9, Stern in view of Takagi further teaches the system of claim 1 as detailed above.
Stern further teaches:
The system according to claim 1, wherein elements of the signatory module are remote to the managed device. (Fig. 6 and Col. 12 line 24 – Col. 13 line 49 disclose a mobile device 10 in communication with an administrative computer, device manager 302. The device manager 302 communicates with the authorization server 304. These communications would require cellular communication between the mobile device, the device manager and the authorization server where each are remote from the others)
Regarding claim 10, claim 10 is canceled.
Regarding claim 12, Stern in view of Takagi further teaches the system of claim 1 as detailed above.
Stern further teaches:
The system according to claim 1, wherein the authorization key is stored on one or more of a smart card, a universal serial bus (USB) stick, a dongle. (Col. 4 line 61 – Col. 5 line 8 and Col. 12 Lines 39-54 disclose that a request can be transmitted via UICC, microSD, or removable media encompassing a USB, dongle, or YubiKey. In order for a request to be transmitted the authorization key would have to present on the media. Since the device is presented with USB adapter the storage devices above would qualify to be used as secure storage for the mobile device.)
Regarding claim 13, Stern in view of Takagi further teaches the system of claim 1 as detailed above.
The system according to claim 1, wherein the authorization key is associated with a particular system user. (Col. 17 lines 4-15 disclose the device manager when a system persona is created will the device manager will generate a public encryption key which is then signed by the persona with is CA which is then stored in in the devices secure element. Each persona will have their own PEK signed by their respective CA.)
Claim(s) 14-15, 18, 21 and 23-24 is/are rejected under 35 U.S.C. 103 as being unpatentable over Stern (US 9819661 B2 filed: 09/12/2013), in view of Takagi et al. (US 2020/0186533 A1 filed: 12/04/2019), and Peuhkurinen et al. (US 2019/0236312 filed 2016).
Regarding claim 14, Stern teaches the method for device management and authorization.
A method for secure approval of an operation requested by a device management system, the method comprising:
receiving, by a management module, (device manager 302 of Fig. 1) an operation request associated with an operation to be performed; (Col. 12 line 24 – Col 13 line 49, Fig. 6 disclose a device manager that facilitates communication with the authorization server, equated to applicant’s signatory module. The device manager will receive or generate then transmit a request to the authorization server. The request includes: identification of device, the operation to be performed, time period, and location. The request is further signed by private key.)
transmitting, by the management module to a signatory module (authorization server 304 of Fig. 1) , the operation request associated with the operation; (Col. 12 line 24 – Col 13 line 49, Fig. 6 disclose a device manager that facilitates communication with the authorization server, equated to applicant’s signatory module. The device manager will receive or generate then transmit a request to the authorization server. The request includes: identification of device, the operation to be performed, time period, and location. The request is further signed by private key.)
Wherein elements of the signatory module are remote to the management module (authorization server 304 of Fig. 1 distinct from device manager 302 of Fig. 1)
(PKI) environment provided and controlled by the system user (Col. 4 line 61 – Col. 5 line 8) independently of the management module (device manager 302 of Fig. 1)
…
receiving, by the management module from the signatory module, an authorized operation response, responsive to authorization of the operation request by the authorized user, (col. 13 lines 24-31 “DM 302 receives the authorization response and determines whether the authorization token authorizes the requested operation. … DM 302 then transmits the authorization response file to mobile communication device 10”) the authorized operation response including information indicative of the operation and an authorization key; (Col. 12 line 24 – Col. 13 line 49 discloses an authorization server that after receive the request will verify the signature and determine operation parameters align with policies. The authorization server will then generate and send a response to the manager that includes: the initial request, an authorization token and signature by the server.) the information indicative of the authorization key associated with the PKI environment (Col. 12 line 24 – Col. 13 line 49 and Col. 17 lines 4-15 disclose a PKI environment for communication between device, manager, and authentication server.)
transmitting, by the management module to a managed device provisioned by the system user with information indicative of the authorization key, (Col. 9 line 40 – col. 9 line 51 discloses “the security policy of first persona 110 may only be configured by a first persona owner, and the security policy of second persona 120 may only be configured by a second persona owner. More specifically, each security policy may be signed by the private key of the persona owner and the signature may be validated by mobile communication device 10 using a corresponding public key of the persona owner before security supervisor 108 applies to security policy to the associated persona.” This is discussing Fig. 3, which is the hardware of the mobile communication device 10) an authorized operation request that includes information indicative of the operation and the authorization key, the managed device responsive to the authorized operation request upon verification of the authorized operation request. (Col. 12 line 24 – Col. 13 line 49 discloses that the device manager will transmit the authorized operation request and related data to the managed device. The managed device will verity the authenticity of the response and if valid will perform the requested operation.)
Stern does not explicitly disclose:
located on premises of a system user
…
wherein the transmitting includes delegating a signature operation to a local authorization device integrated with a public key infrastructure (PKI) environment, and wherein the local authorization device is configured to store or hold an authorization key;
…
Enabling, by the signatory module an authorized user associated with the system user to review the operation request and authorize or reject the operation request
Takagi discloses:
located on premises of a system user (“The terminal device 100 and the providing server 200 are, the terminal device 100 and the authentication server 300 are, and the providing server 200 and the authentication server 300 are communicably coupled to each other via a network N. As the network N, any type of communication network such as a local area network (LAN) ” ¶ 34)
and wherein the transmitting includes delegating a signature operation to a local authorization device integrated with a public key infrastructure (PKI) environment, (“the signature request unit 282 notifies the signature unit 44 of the external authenticator 400 of the process name and the front display application information. When the process name with the signature and the front display application information with the signature, which are signed in the signature unit 44, are received, the signature request unit 282 transmits the received information to the server verification cooperation unit 242.” Takagi ¶ 52) and wherein the local authorization device is configured to store or hold an authorization key; (“The key management unit 42 manages the private key. The key management unit 42 may, as the private key, separately manage a private key used for the above-described authentication processing (FIG. 2)” Takagi ¶ 41)
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Stern with Takagi by providing the external authenticator of Takagi to perform signature operations (e.g. Takagi Fig. 2) and integrating the elements of the system together in a LAN rather than over the internet (Takagi Fig. 1). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Stern with Takagi in order to perform multi-factor-authentication using an external token, thereby increasing security of the authentication and signature.
Stern in view of Takagi does not disclose: Enabling, by the signatory module an authorized user associated with the system user to review the operation request and authorize or reject the operation request
Peuhkurinen discloses: Enabling, by the signatory module an authorized user associated with the system user to review the operation request and authorize or reject the operation request
(“FIG. 4 illustrates an exemplary permissions prompt 400 that may be displayed to allow a user to grant or deny a requested access permission according to aspects of the disclosed embodiments. The prompt 400 may be displayed to the user via the user interface 170 when the permission manager 152 requires an input 106 from a user. The prompt 400 displays information 402 clearly describing the access permission being requested.” Peuhkurinen ¶ 50. See Peuhkurinen Fig. 6 showing distributed processes with multiple users.)
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Stern in view of Takagi with Peuhkurinen by providing a permission request prompt at the signing server before authorizing the request of Stern (e.g. the request of Stern cols 12-13). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Stern in view of Takagi with Peuhkurinen in order to improve access control mechanisms that can apply permissions and privileges across multiple environments and computing devices, Peuhkurinen ¶¶ 5-6.
Regarding claim 15, Stern in view of Takagi and Peuhkurinen further teaches the method of claim 14 as detailed above.
Stern further teaches:
The method according to claim 14, wherein the authorized operation request includes information indicative of the operation request and a proof of authorization. (Col. 12 line 24 – Col. 13 line 49 disclose the authorized operation request includes: the initial request, an authorization token and signature by the server. The initial request includes: identification of device, the operation to be performed, time period, and location.)
Regarding claim 18, Stern in view of Takagi and Peuhkurinen further teaches the method of claim 14 as detailed above.
Stern further teaches:
The method according to claim 14, further comprising receiving a certificate chain associated with the authorization key. (Col. 13 lines 35-49 disclose when the mobile device receives the authorization response the signatures with its private key. The response can also include a certificate chain to an authorization root of trust for additional proof of authorization.)
Regarding claim 21, Stern teaches the apparatus for device management and authorization.
Stern teaches:
An apparatus comprising:
a processor; and (Stern Fig. 3)
a non-transient memory for storing instructions that when executed by the processor cause the apparatus to be configured to:
receiving, by a management module, (device manager 302 of Fig. 1) an operation request associated with an operation to be performed; (Col. 12 line 24 – Col 13 line 49, Fig. 6 disclose a device manager that facilitates communication with the authorization server, equated to applicant’s signatory module. The device manager will receive or generate then transmit a request to the authorization server. The request includes: identification of device, the operation to be performed, time period, and location. The request is further signed by private key.)
transmitting, by the management module to a signatory module (authorization server 304 of Fig. 1) , the operation request associated with the operation; (Col. 12 line 24 – Col 13 line 49, Fig. 6 disclose a device manager that facilitates communication with the authorization server, equated to applicant’s signatory module. The device manager will receive or generate then transmit a request to the authorization server. The request includes: identification of device, the operation to be performed, time period, and location. The request is further signed by private key.)
Wherein elements of the signatory module are remote to the management module (authorization server 304 of Fig. 1 distinct from device manager 302 of Fig. 1)
…
(PKI) environment provided and controlled by the system user (Col. 4 line 61 – Col. 5 line 8) independently of the management module (device manager 302 of Fig. 1)
…
receiving, by the management module from the signatory module, an authorized operation response …, an authorized operation response including the information indicative of the operation and an authorization key; (Col. 12 line 24 – Col. 13 line 49 discloses an authorization server that after receive the request will verify the signature and determine operation parameters align with policies. The authorization server will then generate and send a response to the manager that includes: the initial request, an authorization token and signature by the server.) the information indicative of the authorization key associated with the PKI environment (Col. 12 line 24 – Col. 13 line 49 and Col. 17 lines 4-15 disclose a PKI environment for communication between device, manager, and authentication server.)
transmitting, by the management module to a managed device, the authorized operation request that includes information indicative of the operation and the authorization key, the managed device responsive to the authorized operation request upon verification of the authorized operation request. (Col. 12 line 24 – Col. 13 line 49 discloses that the device manager will transmit the authorized operation request and related data to the managed device. The managed device will verity the authenticity of the response and if valid will perform the requested operation.)
Stern does not explicitly disclose:
located on premises of a system user
…
wherein the transmitting includes delegating a signature operation to a local authorization device integrated with a public key infrastructure (PKI) environment, and wherein the local authorization device is configured to store or hold an authorization key;
…
Enabling, by the signatory module an authorized user associated with the system user to review the operation request and authorize or reject the operation request
… responsive to authorization of the operation request by the authorized user
Takagi discloses:
and wherein the transmitting includes delegating a signature operation to a local authorization device integrated with a public key infrastructure (PKI) environment, (“the signature request unit 282 notifies the signature unit 44 of the external authenticator 400 of the process name and the front display application information. When the process name with the signature and the front display application information with the signature, which are signed in the signature unit 44, are received, the signature request unit 282 transmits the received information to the server verification cooperation unit 242.” Takagi ¶ 52) and wherein the local authorization device is configured to store or hold an authorization key; (“The key management unit 42 manages the private key. The key management unit 42 may, as the private key, separately manage a private key used for the above-described authentication processing (FIG. 2)” Takagi ¶ 41)
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Stern with Takagi by providing the external authenticator of Takagi to perform signature operations (e.g. Takagi Fig. 2) and integrating the elements of the system together in a LAN rather than over the internet (Takagi Fig. 1). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Stern with Takagi in order to perform multi-factor-authentication using an external token, thereby increasing security of the authentication and signature.
Stern in view of Takagi does not disclose:
Enabling, by the signatory module an authorized user associated with the system user to review the operation request and authorize or reject the operation request
… responsive to authorization of the operation request by the authorized user
Peuhkurinen discloses: Enabling, by the signatory module an authorized user associated with the system user to review the operation request and authorize or reject the operation request
… responsive to authorization of the operation request by the authorized user
(“FIG. 4 illustrates an exemplary permissions prompt 400 that may be displayed to allow a user to grant or deny a requested access permission according to aspects of the disclosed embodiments. The prompt 400 may be displayed to the user via the user interface 170 when the permission manager 152 requires an input 106 from a user. The prompt 400 displays information 402 clearly describing the access permission being requested.” Peuhkurinen ¶ 50. See Peuhkurinen Fig. 6 showing distributed processes with multiple users.)
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Stern in view of Takagi with Peuhkurinen by providing a permission request prompt at the signing server before authorizing the request of Stern (e.g. the request of Stern cols 12-13). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Stern in view of Takagi with Peuhkurinen in order to improve access control mechanisms that can apply permissions and privileges across multiple environments and computing devices, Peuhkurinen ¶¶ 5-6.
Regarding claim 23, Stern in view of Takagi and Peuhkurinen further teaches the apparatus of claim 21 as detailed above.
Stern further teaches:
The apparatus according to claim 21, wherein instructions when executed by the processor cause the apparatus to be further configured to receive a certificate chain associated with the authorization key. (Col. 13 lines 35-49 disclose when the mobile device receives the authorization response the signatures with its private key. The response can also include a certificate chain to an authorization root of trust for additional proof of authorization.)
Regarding claim 24, Stern in view of Takagi and Peuhkurinen further teaches the apparatus of claim 23 as detailed above.
Stern further teaches:
The apparatus according to claim 23, wherein instructions when executed by the processor cause the apparatus to be further configured to store the authorization key and the certificate chain on one or more of a smart card, a universal serial bus (USB) stick, a dongle and a YubiKey. (Col. 4 line 61 – Col. 5 line 8 and Col. 12 Lines 39-54 disclose that a request can be transmitted via UICC, microSD, or removable media encompassing a USB, dongle, or YubiKey. In order for a request to be transmitted the authorization key would have to present on the media. Since the device is presented with USB adapter the storage devices above would qualify to be used as secure storage for the mobile device.)
Claims 8, and 11, are rejected under 35 U.S.C. 103 as being unpatentable over Stern (US 9819661 B2 filed: 09/12/2013), in view of Takagi et al. (US 2020/0186533 A1 filed: 12/04/2019), and Nadalin (US 20050278534 A1 filed: 05/27/2004).
Regarding claim 8, Stern in view of Takagi further teach the system of claim 1 as detailed above.
Stern further teaches:
The system according to claim 1, prior to verification of the authorization key. (Fig. 6 and Col. 12 line 24 – Col. 13 line 49 disclose verification of the authorization key.)
Stern in view of Takagi does not teach:
wherein the signatory module performs a revocation status check
Nadalin teaches:
wherein the signatory module performs a revocation status check (Fig.4 and Paragraph [0044] discloses a system for preforming revocation status check.)
Both Stern and Nadalin are directed towards device authorization. It would have been obvious to a PHOSITA before the effective filing date to modify the teaching of Stern in view of Takagi to include the certificate revocation status check as taught by Nadalin for the purpose of providing extra security and allowing authorization verification to only be undergone on transactions proven valid by the associated certification. (Nadalin Paragraph [0044]) This change would be a simple procedure which would not require any extra experimentation to perform this check prior to verification and would yield predictable results.
Regarding claim 11, Stern in view of Takagi further teach the system of claim 1 as detailed above.
Nadalin teaches:
The system according to claim 10, wherein the PKI environment is a X. 509 environment. (Paragraph [0007] discloses that an X.509 environment is an International Telecommunications Union (ITU) standard in the art for a PKI environment.)
Both Stern and Nadalin are directed towards device authorization. It would have been obvious to a PHOSITA before the effective filing date to modify the teaching of Stern in view of Takagi to include the X.509 PKI environment as taught by Nadalin for the purpose of conforming to the ITU and cryptographically binds the holder and key. (Nadalin Paragraph [0007]) This change would be a simple procedure which would not require any extra experimentation and would yield predictable results.
Claims 17, 19, 20 and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Stern (US 9819661 B2 filed: 09/12/2013), in view of Takagi et al. (US 2020/0186533 A1 filed: 12/04/2019), Peuhkurinen et al. (US 2019/0236312 filed 2016), and Nadalin (US 20050278534 A1 filed: 05/27/2004).
Regarding claim 17, Stern in view of Takagi and Peuhkurinen teach the method of claim 14 as detailed above.
Stern further teaches:
The method according to claim 14, prior to verification of the authorization key. (Fig. 6 and Col. 12 line 24 – Col. 13 line 49 disclose verification of the authorization key.)
Stern in view of Takagi and Peuhkurinen does not teach:
further comprising performing a revocation status check
Nadalin teaches:
further comprising performing a revocation status check (Fig. 4 and Paragraph [0044] discloses a system for preforming revocation status check.)
Both Stern and Nadalin are directed towards device authorization. It would have been obvious to a PHOSITA before the effective filing date to modify the teaching of Stern in view of Takagi to include the certificate revocation status check as taught by Nadalin for the purpose of providing extra security and allowing authorization verification to only be undergone on transactions proven valid by the associated certification. (Nadalin Paragraph [0044]) This change would be a simple procedure which would not require any extra experimentation to perform this check prior to verification and would yield predictable results.
Regarding claim 19, Stern in view of Takagi, Peuhkurinen and Nadalin further teach the method of claim 17 as detailed above.
Stern further teaches:
The method according to claim 17, further comprising storing a certificate chain. (Col. 4 line 61 – Col. 5 line 8, Col. 9 lines 51-58 and Col. 15 lines 10-20 disclose a secure storage contains slots for each persona which would operate as a keystore for PKI, encryption keys, passwords and configuration information. Stern discloses trust anchors which are equated to applicants’ certificates, theses anchors would be stored within secure storage. When the proof of authorization is sent to the device a certificate chain is also sent and would be further stored in the secure storage.)
Regarding claim 20, Stern in view of Takagi, Peuhkurinen, and Nadalin further teaches the method of claim 19 as detailed above.
Stern further teaches:
The method according to claim 19, wherein the authorization key and the certificate chain are stored on one or more of a smart card, a universal serial bus (USB) stick, a dongle and a YubiKey. (Col. 4 line 61 – Col. 5 line 8 and Col. 12 Lines 39-54 disclose that a request can be transmitted via UICC, microSD, or removable media encompassing a USB, dongle, or YubiKey. In order for a request to be transmitted the authorization key would have to present on the media. Since the device is presented with USB adapter the storage devices above would qualify to be used as secure storage for the mobile device.)
Regarding claim 22, Stern in view of Takagi and Peuhkurinen teach the apparatus of claim 21 as detailed above.
Stern further teaches:
The apparatus according to claim 21, wherein instructions when executed by the processor cause the apparatus prior to verification of the authorized operation request.
(Fig. 6 and Col. 12 line 24 – Col. 13 line 49 disclose verification of the authorization key.)
Stern in view of Takagi and Peuhkurinen does not teach:
to be further configured to perform a revocation status check
Nadalin teaches:
to be further configured to perform a revocation status check (Fig. 4 and Paragraph [0044] discloses a system for preforming revocation status check.)
Both Stern and Nadalin are directed towards device authorization. It would have been obvious to a PHOSITA before the effective filing date to modify the teaching of Stern in view of Takagi to include the certificate revocation status check as taught by Nadalin for the purpose of providing extra security and allowing authorization verification to only be undergone on transactions proven valid by the associated certification. (Nadalin Paragraph [0044]) This change would be a simple procedure which would not require any extra experimentation to perform this check prior to verification and would yield predictable results.
Claims 3 and 5 are rejected under 35 U.S.C. 103 as being unpatentable over Stern (US 9819661 B2 A1 filed: 09/12/2013) in view of Takagi et al. (US 2020/0186533 A1 filed: 12/04/2019), and Sherkin (US 20090161876 A1 filed: 07/28/2009).
Regarding claim 3, Stern in view of Takagi further teach the system of claim 2 as detailed above.
Stern further teaches:
The system according to claim 2, wherein the proof of authorization is one or more of and a signature. (Col. 12 line 24 – Col. 13 line 49 disclose the authorized operation request includes: the initial request, an authorization token and signature by the server. The initial request includes: identification of device, the operation to be performed, time period, and location.)
Stern in view of Takagi does not teach:
A password
Sherkin teaches:
A password (Paragraphs [0038] and [0042] disclose a response sent by the server to the client the response contains the client and server certificates or the client’s user name, password, and server certificates. The received information is verified for the authenticity of the information.)
Both Stern and Sherkin are directed towards device and client authorization. It would have been obvious to a PHOSITA before the effective filing date to modify the teaching of Stern in view of Takagi to include a password in the response as a form of proof of authorization as taught by Sherkin for the purpose of providing an additional element to show proof of authorization. (Sherkin Paragraphs [0038] and [0042])
Regarding claim 5, Stern in view of Takagi further teach the system of claim 1 as detailed above.
Stern further teaches:
The system according to claim 1, wherein the information indicative of an authorization key is one or more of a root certificate authority certificate (Col. 6 lines 38-65 disclose trust anchors, cryptographic signatures, that are used to verify persona authenticity and are directly tied to personas individual keys for PKI. Each trust anchor root traces back to the root certificate authority. Each persona has their own slot within the secure element to store sensitive information including the information indicative of an authorization key; the root of trust, used to by the trust platform modules to provide isolation of the personas, and the user credentials.)
Stern in view of Takagi does not teach:
And a password
Sherkin teaches:
And a password (Paragraphs [0038] and [0042] disclose that the client credentials comprise a user name and password that are sent to the server as a form of information indicative of an authorization key.)
Both Stern and Sherkin are directed towards device and client authorization. It would have been obvious to a PHOSITA before the effective filing date to modify the teaching of Stern in view of Takagi to include a password in the operation request as an authorization key as taught by Sherkin for the purpose of providing an additional element to show proof of identity of a request initializer. (Sherkin Paragraphs [0038] and [0042]) This change would be a simple procedure which would not require any extra experimentation to include the password as part of the information indicative of an authorization key, which is stored in secure element as taught by Stern, and would yield predictable results.
Claim 16 are rejected under 35 U.S.C. 103 as being unpatentable over Stern (US 9819661 B2 A1 filed: 09/12/2013) in view of Takagi et al. (US 2020/0186533 A1 filed: 12/04/2019), Peuhkurinen et al. (US 2019/0236312 filed 2016), and Sherkin (US 20090161876 A1 filed: 07/28/2009).
Regarding claim 16 Stern in view of Takagi and Peuhkurinen teach the method of claim 15 as detailed above.
Stern further teaches:
The method according to claim 15, wherein the proof of authorization is one or more of and a signature. (Col. 12 line 24 – Col. 13 line 49 disclose the authorized operation request includes: the initial request, an authorization token and signature by the server. The initial request includes: identification of device, the operation to be performed, time period, and location.)
Stern in view of Takagi and Peuhkurinen does not teach:
A password
Sherkin teaches:
A password (Paragraphs [0038] and [0042] disclose a response sent by the server to the client the response contains the client and server certificates or the client’s user name, password, and server certificates. The received information is verified for the authenticity of the information.)
Both Stern and Sherkin are directed towards device and client authorization. It would have been obvious to a PHOSITA before the effective filing date to modify the teaching of Stern in view of Takagi to include a password in the response as a form of proof of authorization as taught by Sherkin for the purpose of providing an additional element to show proof of authorization. (Sherkin Paragraphs [0038] and [0042])
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
1. US 2019/0068373 – Konduru
- Policy Based Authentication
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Rupal Dharia can be reached at 571-272-3880. The examiner can normally be reached Monday - Friday 6:30 A.M.- 3:00 P.M. E.D.T..
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.
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.
/RUPAL DHARIA/Supervisory Patent Examiner, Art Unit 2492
Prosecution Insights