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 .
DETAILED ACTION
This action is in response to the application filed on 06/25/2025.
Claims 1-6, 8, 10, 13-18 and 21-24 are pending.
Claim Objections
Claim(s) 14 is/are objected to because of the following informalities:
Regarding claim 14, the examiner recommends amending the limitation as follows “wherein the operations further comprise: in response to a selection of the user interface control in the second configuration” as the first selection introduced in the dependent claim is not of the user interface control in the second configuration.
Appropriate correction required.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
The following analysis is according to the 2019 revised patent subject matter eligibility guidance (2019 PEG).
Claims 1-10, 13-18 and 21-24 are rejected under 35 U.S.C. 101 because the claimed invention recites a judicial exception, is directed to that judicial exception, an abstract idea, as it has not been integrated into practical application and the claims further do not recite significantly more than the judicial exception. Examiner has evaluated the claims under the framework provided in the 2019 Patent Eligibility Guidance published in the Federal Register 01/07/2019 and has provided such analysis below.
Step 1: Claims 1-10 are directed to a method and fall within the statutory category of processes. Claims 13-18 are directed to an apparatus and fall within the statutory category of machine. Claims 21-24 are directed to a non-transitory computer-readable medium and falls under manufacture. Therefore, “Are the claims directed to a process, machine, manufacture or composition of matter?” Yes.
In order to evaluate the Step 2A inquiry “Is the claim directed to a law of nature, a natural phenomenon or an abstract idea?” we must determine, at Step 2A Prong 1, whether the claim recites a law of nature, a natural phenomenon or an abstract idea and further whether the claim recites additional elements that integrate the judicial exception into a practical application.
Step 2A Prong 1:
Claims 1, 13, 21: The limitations of claim 1, 13, 21 “determining a status condition of the application related to whether installation of the application involves an installation request, by communicating with a management unit associated with the managed devices using an application programming interface”, as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can think and observe, judge and evaluate a setting to realize that it has been activated/turned on/enabled. For instance, based on instant specification [0043] where the application request setting may be a value. A user may look at a value of the application request setting and evaluate that it has been enabled if the value is 1 or the user may look at setting on an interface and check a toggle button and evaluate that the setting has been enabled. Thus, any of the aforementioned exemplary tasks can be performed as mental observations and evaluations.
Therefore, Yes, claims 1, 13, 21 recite judicial exceptions.
The claims have been identified to recite judicial exceptions, Step 2A Prong 2 will evaluate whether the claims are directed to the judicial exception.
Step 2A Prong 2:
Claims 1, 13, 21: The judicial exception is not integrated into a practical application. In particular, the claim recites the following additional elements – “computing device”, “user device”, processor which are mere recitation of generic computing components and functions merely applying the abstract idea using (see MPEP § 2106.05(f)) which does not integrate a judicial exception into practical application. Further, the claims recite the following additional elements – claim(s) 1, 13, 21 “receiving, selection of an application on a user interface of an application store platform, the application store platform providing a plurality of applications compatible with managed devices and non-managed devices”, “transmitting, over a network, a status request to the management unit associated with the managed devices, the status request including an application identifier of the application; and”, “receiving, over the network, a status response from the management unit, the status response identifying the status condition; and”, “in response to the status condition being a first status condition, rendering the user interface control of the application store platform in a first configuration, the user interface control in the first configuration providing a first option to request permission to install the application”, “in response to the status condition being a second status condition, rendering the user interface control in a second configuration, the user interface control in the second configuration providing a second option to install the application on a user device” are mere data gathering steps and are insignificant extra solution activity for displaying and transmitting data. See MPEP 2106.05(g). The step “configuring a user interface control of the application store platform based on the status condition” is an apply it step with mere instructions to implement an abstract idea on a computer or merely uses a computer a tool to perform an abstract idea.
Thus, the additional elements do not integrate the judicial exception into practical application.
Therefore, “Do the claims recite additional elements that integrate the judicial exception into a practical application? No, these additional elements do not integrate the abstract idea into a practical application and they do not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
After having evaluating the inquires set forth in Steps 2A Prong 1 and 2, it has been concluded that claim(s) 1, 13, 21 not only recites a judicial exception but that the claim is directed to the judicial exception as the judicial exception has not been integrated into practical application.
Step 2B:
Claim(s) 1, 13, 21: The claims do not include additional elements, alone or in combination, that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements amount to no more than generic computing components merely applying the abstract idea and field of use/technological environment. Claim(s) 1, 13, 21 recite receiving and transmitting limitations which are Well-Understood, Routine, Conventional (WURC). The receiving and transmitting limitations are WURC akin to Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network); but see DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1258, 113 USPQ2d 1097, 1106 (Fed. Cir. 2014). See MPEP 2106.05(d). See MPEP 2106.05(d). The rendering limitations is also Well-Understood, Routine, Conventional (WURC) Activity akin to akin to presenting data akin to Presenting offers and gathering statistics, OIP Techs., 788 F.3d at 1362-63, 115 USPQ2d at 1092-93;.
Therefore, “Do the claims recite additional elements that amount to significantly more than the judicial exception? No, these additional elements, alone or in combination, do not amount to significantly more than the judicial exception.
Having concluded analysis within the provided framework, Claim(s) 1, 13, 21 do not recite patent eligible subject matter under 35 U.S.C. § 101.
Claim 2 further recites mental steps in the determining and generating steps and recites insignificant extra solution activity akin to mere data gathering/presenting data in the rendering step. Claim 3 further recites mental steps in the determining, generating and modifying steps and recites insignificant extra solution activity akin to mere data gathering in the rendering step. Claim 4 further recites providing an option which is also insignificant extra solution activity akin to mere data gathering/presenting data and the initiating installation step is an “apply it” limitation which is merely an instruction to implement an abstract idea on a computer or merely uses a computer as a tool to perform an abstract idea. See MPEP 2106.05(f). Claims 5-6 further recite rendering steps which is also insignificant extra solution activity akin to mere data gathering/presenting data. See MPEP 2106.05(g). Claim 8 recites storing and receiving data which is also insignificant extra solution activity akin to mere data gathering. Claim 10 also recites transmitting and rendering steps which are insignificant extra solution activity akin to mere data gathering/presenting data. Claim 23 recites an additional detecting step which is also being analyzed as a mental step.
Where claims 2-10 are rejected for their dependence on rejected claim 1 and do not provide additional elements to integrate the judicial exception into a practical application nor amount to significantly more than the judicial exception as shown above.
Claim set 13-18 and claim set 21-24 are similarly rejected to claim set 1-6, 8, 10 for reciting similar language and not providing additional elements to integrate the judicial exception into a practical application nor amount to significantly more than the judicial exception.
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, 4, 6, 13-14, 16-18, 21 and 23 is/are rejected under 35 U.S.C. 103 as being unpatentable over NPL ("Request and install apps from the SharePoint Store", Cerima, 11/08/2021) hereinafter NPL1 in view of Barton et al. (US 2014/0032758 A1) hereinafter Barton and further in view of Grigera (US 9,230,134 B1) and further in view of Young et al. (US 2022/0107845 A1) hereinafter Young and further in view of Li et al. (US 2021/0200536 A1) hereinafter Li.
Regarding claim 1, NPL1 discloses
A method for requesting installation of applications, the method comprising:
configuring a user interface control of the application store platform based on the [status condition] (NPL1 [pg. 8] discloses configuring the store settings based on the user selection of the settings), including:
in response to the status condition being a first [status condition], rendering the user interface control of the application store platform in a first configuration, the user interface control in the first configuration providing a first option to request permission to install the application (NPL1 [pgs. 2-3] discloses an admin or a user with sufficient permission to install apps from the SharePoint Store. Where the user is permitted to click on the Request to submit an installation request as illustrated in NPL1 [pg. 3] based on the setting in SharePoint Admin Center App Settings as illustrated in NPL1 [pg. 7-8]. Thus, the setting “Should end users be able to get apps from the marketplace” set to “No” illustrated in NPL1 [pg. 8] enables the button to request apps for installation by the SharePoint Store as disclosed in the text below the image which changes the configuration to an “Request” button vs “Add”/install button. Where the request option is conceptually similar to the first option); and
in response to the status condition being a second [status condition], rendering the user interface control in a second configuration, the user interface control in the second configuration providing a second option to install the application on a user device (NPL1 [pgs. 8-9] illustrates the configuration data that may be configured to modify the User interface control which includes end users being able to get apps from the marketplace and apps for office from the store to be able to start when documents are opened in a browser. Where if “Yes” is selected in the first configuration option, then the user will see the button “Add” for installing the application as the second option. Thus, based on the configuration data, the User interface control is modified with different buttons which may even be enabled or disabled based on permission configuration data NPL1 [pg. 1]).
NPL1 lacks explicitly disclosing
receiving, selection of an application on a user interface of an application store platform, the application store platform providing a plurality of applications compatible with managed devices and non-managed devices;
determining a status condition of the application related to whether installation of the application involves an installation request, by communicating with a management unit associated with the managed devices using an application programming interface, including:
transmitting, over a network, a status request to the management unit associated with the managed devices, the status request including an application identifier of the application; and
receiving, over the network, a status response from the management unit, the status response identifying the status condition; and
configuring a user interface control of the application store platform based on the status condition
Barton teaches
receiving, selection of an application on a user interface of an application store platform, the application store platform providing a plurality of applications compatible with managed devices and non-managed devices (Barton [0536], [0545] teaches the user to select desired applications from the application store which includes a plurality of applications to run on the mobile device in one of a plurality of operating modes. Barton [0131] teaches the app store may be a web browser. Barton teaches [0133]-[0134] teaches distributing applications to unmanaged devices and [0176] teaches installing application on managed devices through enterprise mobility management (EMM) client and [0555] teaches the operation modes may comprise managed and unmanaged modes);
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 NPL1 to incorporate the teachings of Barton by adding the following feature of “receiving, by a browser application executable by a user device managed by an organization, selection of an application on a user interface of a public application store platform, the public application store platform providing a plurality of applications for installation on managed devices and non-managed devices” in order to efficiently allow users to access enterprise applications from their own mobile devices, where the enterprise applications securely coexist with the users’ own personal applications and data (Barton [0534]) which increases user control and user satisfaction through selecting applications wanted and needed.
Grigera teaches
determining a status condition of the application related to whether installation of the application involves an installation request, by communicating with a management unit associated with the managed devices using an application programming interface (Grigera [col. 8, lines 24-41] teaches when device management 690 receives a request to view, download, or install application 120 through input unit 670, device management 690, though output 675, provides information about application 120 and metadata 150. Thus, through the request a status condition to install application 120 may be determined versus only viewing the application data. Where the permission management 685 is called by API unit 665), including:
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 NPL1 to incorporate the teachings of Grigera by adding the following feature of “determining a status condition of the application related to whether installation of the application involves an installation request, by communicating with a management unit associated with the managed devices using an application programming interface, including:” in order to efficiently and precisely determine the status of different applications and based on the determination act accordingly.
Young teaches
transmitting, over a network, a status request to the management unit associated with the managed devices, the status request including an application identifier of the application (Young [0065] teaches the management system 206 receiving request to install application in which together the request with the app ID transmitted to the management system is conceptually similar to the status request as illustrated in Fig. 6 elements 602 and 604.); and
receiving, over the network, a status response from the management unit, the status response identifying the status condition (Young [0065] teaches The application manager 216 then creates a message for the managed device 202 as shown at operation 616. The communication hub 210 then sends a message to the managed device 202 (see operation 618). The message includes a command, and installation ID, and application ID, and the application parameters, as shown at operation 620.)
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 NPL1 to incorporate the teachings of Young by adding the following feature of “transmitting, over a network, a status request to the management unit associated with the managed devices, the status request including an application identifier of the application” in order to prevent wasted computing resources from installing incorrect applications and prevent user dissatisfaction.
Li teaches
configuring a user interface control of the application store platform based on the status condition (Li [claim 7] teaches “the software package management system is used for the software repository in claim 1, including following modules: an authentication module, configured to use to authenticate a username and a password of a user, or an application identification and a secret key, and grant different permissions to different accounts based on the role-based access control”)
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 NPL1 to incorporate the teachings of Li by adding the following feature of “configuring a user interface control of the application store platform based on the status condition” in order to improve accuracy on app store configuration and prevent unauthorized users from installing apps.
Regarding claim 4, NPL1 discloses The method of claim 1, further comprising:
in response to a selection of the user interface control in the second configuration, initiating installation of the application on the user device (NPL1 [pg. 8] discloses if “Yes” is selected for the top setting, apps are added/installed versus being requested which is initiated when the “Add” button is clicked instead of the “Send Request” button illustrated on NPL1 [pg. 3]).
Regarding claim 6, The method of claim 1,
NPL1 further discloses in response to the status condition being a third status condition, rendering the user interface control in a third configuration, the user interface control in the third configuration including information indicating that permission to install the application is pending (NPL1 [pg. 4] illustrates in the first image a modified user interface control with information indicating the Smarter Event Booking app is Pending Purchase when the “Should end users be able to get apps from the marketplace” setting is set to “No” thus, requiring users to request applications for installation vs installing the applications instantly. Where starting in the first configuration requiring request for installation, then switching to not requiring a request, and back to requiring the request which illustrates the pending application is similar to the third status condition).
Regarding claim 13, it’s directed to an apparatus having similar limitations cited in claim 1 in addition to the following. Thus claim 13 is also rejected under the same rationale as cited in the rejection of claim 1 above and the following.
An apparatus comprising: at least one processor (NPL1 [pg. 2] illustrates in the first image a computer generated output running the SharePoint Store application which requires a processor to execute the application and computer-readable medium to store the instructions to run the application); and
a non-transitory computer-readable medium storing executable instructions that when executed by the at least one processor cause the at least one processor to (NPL1 [pg. 2] illustrates in the first image a computer generated output running the SharePoint Store application which requires a processor to execute the application and computer-readable medium to store the instructions to run the application).
Regarding claim 14, it’s directed to an apparatus having similar limitations cited in claim 4, second limitation. Thus claim 14 is also rejected under the same rationale as cited in the rejection of claim 4, second limitation above.
Regarding claim 16, it’s directed to an apparatus having similar limitations cited in claim 6. Thus claim 16 is also rejected under the same rationale as cited in the rejection of claim 6.
Regarding claim 18, The apparatus of claim 13, wherein the operations further comprise
NPL1 further discloses
receiving first configuration data for the user interface control based on the first status condition, the first configuration data configured to render the user interface control in the first configuration (NPL1 [pgs. 7-8] discloses finding out if end users are allowed to make app purchases through the Configure Store Settings which would receive the configuration data once the user/administrator clicks on “Open” on the Interface illustrated on NPL1 [pg. 7]); and
rendering the user interface control in the first configuration using to the first configuration data (NPL1 [pg. 9] illustrates the configuration data that may be configured to modify the User interface control which includes end users being able to get apps from the marketplace and apps for office from the store to be able to start when documents are opened in a browser. Thus, if the user selects “No” in the first configuration option, then end users would not be able to immediately install the apps from the marketplace without first requesting the apps and having them approved as illustrated in the first image of NPL1 [pg. 9]. However, if “Yes” is selected in the first configuration option, then the user will see the button “Add” for installing the application. Thus, based on the configuration data, the User interface control is modified with different buttons which may even be enabled or disabled based on permission configuration data as well NPL1 [pg. 1]).
Regarding claim 21, it’s directed to a non-transitory computer-readable medium having similar limitations cited in claim 1 except for the following. Thus claim 21 is also rejected under the same rationale as cited in the rejection of claim 1 above and the following.
A non-transitory computer-readable medium storing executable instructions that when executed by at least one processor cause the at least one processor to execute operations, the operations comprising (NPL1 [pg. 2] illustrates in the first image a computer generated output running the SharePoint Store application which requires a processor to execute the application and computer-readable medium to store the instructions to run the application).
Regarding claim 23, The non-transitory computer-readable medium of claim 21, wherein the operations further comprise:
detecting a request to display information of the application store platform (NPL1 [pg. 7] discloses clicking on “Configure Store Settings” which would display information of the app store as illustrated in the Figure of NPL1 [pg. 8]);
receiving configuration data for the user interface control in the second configuration (NPL1 [pg. 8] illustrates in the Figure receiving configuration data when selecting “No” versus “Yes”); and
modifying the user interface control from the first configuration to the second configuration (NPL1 [pg. 8] if “Yes” is selected in the top configuration option, then the user will see the button “Add” for installing the application thus, changing from the first configuration of requesting to install to the second configuration of adding/installing the app instantly).
Claim(s) 2-3 is/are rejected under 35 U.S.C. 103 as being unpatentable over NPL ("Request and install apps from the SharePoint Store", Cerima, 11/08/2021) hereinafter NPL1 in view of Barton et al. (US 2014/0032758 A1) hereinafter Barton and further in view of Grigera (US 9,230,134 B1) and further in view of Young et al. (US 2022/0107845 A1) hereinafter Young and further in view of Li et al. (US 2021/0200536 A1) hereinafter Li and further in view of Mangtani et al. (US 9,268,562 B1) hereinafter Mangtani.
Regarding claim 2, NPL1 in view of Barton and further in view of NPL1 combination teach The method of claim 1, further comprising:
Where NPL1 teaches rendering the user interface control based on selected/enabled setting but lacks the details of the limitations below
the combination lacks explicitly
determining, at a first time, that the application has the first status condition;
generating first configuration data for the user interface control based on the first status condition, the first configuration data configured to render the user interface control in the first configuration; and
rendering the user interface control in the first configuration using the first configuration data.
Mangtani teaches
determining, at a first time, that the application has the first status condition (Mangtani [col. 11, lines 5-20] teaches mobile workbench may allow developer to drag and drop section, select other options to be included in the layout, toggling feature flags, and/or editing layout settings as illustrated in Fig. 8 and 10. Mangtani [col. 11, lines 22-33] generating data structure used to construct a mobile configuration file as the developer defines mobile application layout feature and setting selections and/or after the developer has completed and save the mobile application layout. Thus, each time the developer modifies/updates the layout and settings, new layout and settings are determined as a status condition. As illustrated in Fig. 10, the first status condition may be determined that the application needs to “search as you type”, “search refinements”, and include “product ratings”. );
generating first configuration data for the user interface control based on the first status condition, the first configuration data configured to render the user interface control in the first configuration (Mangtani [col. 11, lines 28-33] teaches the mobile workbench 104 can generate 306 a mobile configuration data structure 120, e.g., based on the developer's drag-and-drop activity, toggled options, and/or other selections and/or edits through the mobile workbench 104. Mangtani [col. 4, lines 66-67] and [col. 5, lines 15] teaches generating configuration data structure based on administrator’s selections to instruct a mobile application to render a graphical user interface on a display for a mobile device based on the layout modification and without altering the code in the mobile application executable object); and
rendering the user interface control in the first configuration using the first configuration data (Mangtani [col. 14, lines 18-27] teaches rendering the main screen of the mobile application by using the received updated and/or new mobile configuration file/configuration data structure to construct the main screen layout. Where Mangtani [col. 11, lines 44-58] teaches each data structure can be incorporated into an aggregated data structure included in the mobile configuration file).
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 combination to incorporate the teachings of Mangtani by adding the following feature of “determining, at a first time, that the application has the first status condition; generating first configuration data for the user interface control based on the first status condition, the first configuration data configured to render the user interface control in the first configuration; and rendering the user interface control in the first configuration using the first configuration data” in order to decrease the amount of data and/or time used to update an interface, and/or eliminate the need to submit configuration updates for code review (Mangtani [col. 1, lines 41-46]).
Regarding claim 3, the combination teaches The method of claim 2, further comprising:
Where NPL1 teaches rendering the user interface control based on selected/enabled setting but lacks the details of the limitations below
the combination lacks explicitly
determining, at a second time, that the application has the second status condition;
generating second configuration data for the user interface control based on the second status condition, the second configuration data configured to render the user interface control in the second configuration; and
rendering the user interface control in the second configuration using the second configuration data such that the user interface control is modified from the first configuration to the second configuration.
Mangtani teaches
determining, at a second time, that the application has the second status condition (Mangtani [col. 11, lines 5-20] teaches mobile workbench may allow developer to drag and drop section, select other options to be included in the layout, toggling feature flags, and/or editing layout settings as illustrated in Fig. 8 and 10. Mangtani [col. 11, lines 22-33] generating data structure used to construct a mobile configuration file as the developer defines mobile application layout feature and setting selections and/or after the developer has completed and save the mobile application layout. Thus, each time the developer modifies/updates the layout and settings, new layout and settings are determined as a status condition.);
generating second configuration data for the user interface control based on the second status condition, the second configuration data configured to render the user interface control in a second configuration (Mangtani [col. 11, lines 28-33] teaches the mobile workbench 104 can generate 306 a mobile configuration data structure 120, e.g., based on the developer's drag-and-drop activity, toggled options, and/or other selections and/or edits through the mobile workbench 104. Mangtani [col. 4, lines 66-67] and [col. 5, lines 15] teaches generating configuration data structure based on administrator’s selections to instruct a mobile application to render a graphical user interface on a display for a mobile device based on the layout modification and without altering the code in the mobile application executable object); and
rendering the user interface control in the second configuration using the second configuration data such that the user interface control is modified from the first configuration to the second configuration (Mangtani [col. 14, lines 18-27] teaches rendering the main screen of the mobile application by using the received updated and/or new mobile configuration file/configuration data structure to construct the main screen layout. Where Mangtani [col. 11, lines 44-58] teaches each data structure can be incorporated into an aggregated data structure included in the mobile configuration file. Mangtani [col. 8, lines 30-55] teaches different application layout features that may be selected/activated to modify an application layout which may include an action bar having a light or dark background, search results being shown as a grid or a list, a location/position of different elements, enabled search as you type, etc. Mangtani [col. 13, lines 51-56] teaches processing an updated mobile configuration file, the mobile application can render an updated interface with a modified set of features, with a modified top bar and lower bar as illustrated in Fig. 11).
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 combination to incorporate the teachings of Mangtani by adding the following feature of “determining, at a second time, that the application has the second status condition; generating second configuration data for the user interface control based on the second status condition, the second configuration data configured to render the user interface control in the second configuration; and rendering the user interface control in the second configuration using the second configuration data such that the user interface control is modified from the first configuration to the second configuration” in order to decrease the amount of data and/or time used to update an interface, and/or eliminate the need to submit configuration updates for code review (Mangtani [col. 1, lines 41-46]).
Claim(s) 5, 10 and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over NPL ("Request and install apps from the SharePoint Store", Cerima, 11/08/2021) hereinafter NPL1 in view of Barton et al. (US 2014/0032758 A1) hereinafter Barton and further in view of Grigera (US 9,230,134 B1) and further in view of Young et al. (US 2022/0107845 A1) hereinafter Young and further in view of Li et al. (US 2021/0200536 A1) hereinafter Li and further in view of Hirose (US 2020/0019395 A1).
Regarding claim 5, the combination teaches The method of claim 1,
NPL1 teaches
in response to the status condition being a third status condition (NPL1 [pg. 8] illustrates permitting the switching between the configurations. Where starting in the first configuration requiring request for installation, then switching to not requiring a request, and back to requiring the request which illustrates the pending application is similar to the third status condition)
the combination lacks explicitly
in response to the status condition being a third status condition, rendering the user interface control in a third configuration, the user interface control in the third configuration including information indicating that the application is denied from being installed
Hirose teaches
in response to the [status condition being a third status condition], rendering the user interface control in a third configuration, the user interface control in the third configuration including information indicating that the application is denied from being installed (Hirose [0050] teaches an administrator rejecting installation of an application program as illustrated in Fig. 11 in which a response indicating the rejection is transmitted in response to the rejection button 322 being pressed. Hirose [0043] teaches the response indicating the application has been rejected to be displayed on the display unit 122A of the Terminal Apparatus 120A which would modify the user interface control).
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 NPL1 to incorporate the teachings of Hirose by adding the following feature of “in response to the status condition being a third status condition, rendering the user interface control in a third configuration, the user interface control in the third configuration including information indicating that the application is denied from being installed” in order to efficiently notify a user of a denial outcome to allow the user determine the next steps versus now knowing the output of the request. Thus, this improves overall user satisfaction and understanding of the system.
Regarding claim 10, the combination teaches The method of claim 1,
NPL1 further discloses
changing the user interface control of the application store platform from the first configuration to the second configuration (NPL1 [pgs. 2-3] discloses an admin or a user with sufficient permission to install apps from the SharePoint Store. Where the user is permitted to click on the Request to submit an installation request as illustrated in NPL1 [pg. 3] based on the setting in SharePoint Admin Center App Settings as illustrated in NPL1 [pg. 7-8]. Thus, the setting “Should end users be able to get apps from the marketplace” set to “No” illustrated in NPL1 [pg. 8] enables the button to request apps for installation by the SharePoint Store as disclosed in the text below the image which changes the configuration to an “Request” button vs “Add”/install button. Where the request option is conceptually similar to the first option).
Grigera teaches
wherein the application programming interface is a first programming interface (Grigera [col. 8, line 13] teaches the API unit 665), the method further comprising:
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 NPL1 to incorporate the teachings of Grigera by adding the following feature of “wherein the application programming interface is a first programming interface” in order to efficiently empower developers to reuse complex code and abstract some of the HTTP details.
Barton further teaches
transmitting, via a second application programming interface, a request for permission to install the application to a computing device associated with an administrator of an organization (Barton [0069] teaches a set of APIs for receiving and handling requests);
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 combination to incorporate the teachings of Barton by adding the following feature of “f transmitting, via a second application programming interface, a request for permission to install the application to a computing device associated with an administrator of an organization” in order to increase specialization/modularity, performance, flexibility/innovation, security and resilience by using several different APIs.
the combination lacks explicitly
rendering a notification on a display of the user device, the notification indicating the permission to install the application is approved; and
Hirose further teaches
rendering a notification on a display of the user device, the notification indicating whether the request to install the application is approved (Hirose [0050] teaches if the permit button 321 is pressed, a response indicating permission of the system installation is transmitted).
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 combination to incorporate the teachings of Hirose by adding the following feature of “further comprising: rendering a notification on a display of the user device, the notification indicating whether the request to install the application is approved or denied” in order to efficiently notify a user of a denial or approval outcome to allow the user determine the next steps versus now knowing the output of the request. Thus, this improves overall user satisfaction.
Regarding claim 15, it’s directed to an apparatus having similar limitations cited in claim 5. Thus claim 15 is also rejected under the same rationale as cited in the rejection of claim 5.
Claim(s) 8 and 22 is/are rejected under 35 U.S.C. 103 as being unpatentable over NPL ("Request and install apps from the SharePoint Store", Cerima, 11/08/2021) hereinafter NPL1 in view of Barton et al. (US 2014/0032758 A1) hereinafter Barton and further in view of Grigera (US 9,230,134 B1) and further in view of Young et al. (US 2022/0107845 A1) hereinafter Young and further in view of Li et al. (US 2021/0200536 A1) hereinafter Li and further in view of Navert et al. (US 11,429,384 B1) hereinafter Navert and further in view of Yip et al. (US 2015/0296051 A1) hereinafter Yip.
Regarding claim 8, NPL1 further discloses The method of claim 1, further comprising:
storing application management data at the management unit (NPL1 [pgs. 7-9] discloses checking if end users are allowed to make app purchases by using the stored settings. The administrator may click on Configure Store Settings to retrieve setting data on whether users are allowed to make app purchases. Where NPL1 [pg. 9] illustrates the retrieved saved setting for “Should end users be able to get apps from the marketplace” to be “No”. The administrator may modify this to be “Yes” and Click “OK” to update the stored settings for managing the computing device associated with the organization),
receiving, from a computing device associated with an administrator of an organization, information that enables the application request setting (NPL1 [pgs. 7-9] discloses configuring/receiving app purchases settings in the SharePoint Admin Center where an admin may enable or disable a user to request apps in the SharePoint Store through the “Should end users be able to get apps from the marketplace” setting).
wherein the status condition is determined based on the application management data (NPL1 [pg. 8] discloses based on the retrieved selection of “Yes” or “No” for requesting to install an application versus instantly installing is similar to the status condition).
NPL1 lacks explicitly
the application management data including allowability data indicating whether the plurality of applications are allowed, denied, or blocked, the application management data including information about whether an application request setting is enabled or disabled; and
Navert teaches
the application management data including information about whether an application request setting is enabled or disabled (Navert [col. 17, lines 43-55] teaches using an application programming interface (API) to collect Git repository configuration for each project to determine whether or not a setting is enabled. Where each project would be associated with an organization and the repository configuration data is similar to the application management data. Where the application request setting is explicitly taught by NPL2 and Navert is being used to teach the concept of repository configuration/management data including project/application setting that is enabled or not.); and
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 combination to incorporate the teachings of Navert by adding the following feature of “the application management data including information about whether the application request setting is enabled or disabled” in order to accurately and efficiently obtain determination of setting being enabled in real-time and timely update users/GUIs accordingly that has been stored.
Yip teaches
the application management data including allowability data indicating whether the plurality of applications are allowed (Yip [0064] teaches storing a list of one or more permitted computer programs for installation on client computing device), denied (No rejection required due to “or” language), or blocked (No rejection required due to “or” language),
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 combination to incorporate the teachings of Yip by adding the following feature of “the application management data including allowability data indicating whether a plurality of application are allowed” in order to efficiently increase security by determining whether applications are allowed to be installed.
Regarding claim 22, it’s directed to the non-transitory computer-readable medium having similar limitations cited in claim 8-9. Thus claim 22 is also rejected under the same rationale as cited in the rejection of claim 8-9 above. (Navert [col. 17, lines 43-55] teaches using an application programming interface (API) to collect Git repository configuration for each project to determine whether or not a setting is enabled. Where each project would be associated with an organization and the repository configuration data is similar to the application management data. Where the Git repository is similar to the browser application. Thus, the setting is associated with a browser application as the claim does not define the association)
Claim(s) 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over NPL ("Request and install apps from the SharePoint Store", Cerima, 11/08/2021) hereinafter NPL1 in view of Barton et al. (US 2014/0032758 A1) hereinafter Barton and further in view of Grigera (US 9,230,134 B1) and further in view of Young et al. (US 2022/0107845 A1) hereinafter Young and further in view of Li et al. (US 2021/0200536 A1) hereinafter Li and further in view of Purohit et al. (US 2021/0174634 A1) hereinafter Purohit.
Regarding claim 17, the combination teaches The apparatus of claim 13, wherein the operations further comprise:
in response to the selection of the user interface control in the first configuration (NPL1 [pgs. 2-3] discloses an admin or a user with sufficient permission to install apps from the SharePoint Store. Where the user is permitted to click on the Request to submit an installation request as illustrated in NPL1 [pg. 3] based on the setting in SharePoint Admin Center App Settings as illustrated in NPL1 [pg. 7-8]. Thus, the setting “Should end users be able to get apps from the marketplace” set to “No” illustrated in NPL1 [pg. 8] enables the button to request apps for installation by the SharePoint Store as disclosed in the text below the image which changes the configuration to an “Request” button vs “Add”/install button. Where the request option is conceptually similar to the first option),
the combination lacks explicitly
receiving installation data in response to the request to install being approved, the installation data configured to cause the user device to install the application
Purohit teaches
receiving installation data in response to the request to install being approved, the installation data configured to cause the user device to install the application (Purohit [0085] teaches The regulatory server 342 verifies that the software request blockchain transaction 714 is from the EGM 200 (e.g., based on the digital signature) and that the requested software UIDs (e.g., the associated software images 412) are certified for installation and are approved for the EGM 200 (e.g., based on the machine UID). At operation 722, the regulatory server 342 permissions the EGM 200 for the requested software. More specifically, in some embodiments, the regulatory server 342 may record permission for the EGM 200 to access a software image 412 from the golden images database 332. The regulatory server 342 may add a software permission blockchain transaction 724 “V” to the blockchain 302, including the machine UID and an authorization code encrypted with the public key of the EGM 200 (e.g., thereby allowing only the EGM 200 to access the code), and may include an image hash of the software image 412, software configuration settings, or the like. The software permission blockchain transaction 724 serves to memorialize the permissioning of the EGM 200 for access to the software image 718 and provide the authorization code to the EGM 200 (e.g., to facilitate download)).
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 combination to incorporate the teachings of Purohit by adding the following feature of “receiving installation data in response to the request to install being approved, the installation data configured to cause the user device to install the application” in order to prevent wasted computing resources from downloading incorrect software and prevent unauthorized users from accessing enterprise software.
Claim(s) 24 is/are rejected under 35 U.S.C. 103 as being unpatentable over NPL ("Request and install apps from the SharePoint Store", Cerima, 11/08/2021) hereinafter NPL1 in view of Barton et al. (US 2014/0032758 A1) hereinafter Barton and further in view of Grigera (US 9,230,134 B1) and further in view of Young et al. (US 2022/0107845 A1) hereinafter Young and further in view of Li et al. (US 2021/0200536 A1) hereinafter Li and further in view of Hahn et al. (US 2021/0240460 A1) hereinafter Hahn.
Regarding claim 24, the combination lacks explicitly The non-transitory computer-readable medium of claim 21,
the combination lacks
wherein the request to install the application includes an application identifier of the application and a source identifier that identifies the user device
Hahn teaches
wherein the request to install the application includes an application identifier of the application and a source identifier that identifies the user device (Hahn [0136] teaches “In various embodiments, the application bundle installation request may comprise a collection of data associated with an application bundle identifier that is transmitted by a client device 102 associated with a user identifier associated with a user to the group-based communication server 110 as a result of the user indicating a desire to install an application bundle associated with the application bundle identifier within a group-based communication workspace associated with the user identifier. For example, an application bundle installation request may be associated with the user identifier associated with a group-based communication workspace identifier, the user and/or a client device 102 associated therewith, the application bundle identifier, and each of the plurality of applications associated with the application bundle identifier.”).
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 combination to incorporate the teachings of Hahn by adding the following feature of “wherein the request to install the application includes an application identifier of the application and a source identifier that identifies the user device” in order to efficiently increase security by determining whether applications are allowed to be installed and accurately identify both the application and the device.
Response to Arguments
Response to 101 arguments
Regarding the remarks that the configuring limitation integrates the judicial exception into a practical application, the examiner would like to point out that the configuring limitation is analyzed as an “apply it” step which does not integrate the judicial exception into a practical application as the step merely uses a computer to perform an abstract idea. Further, the rendering steps are merely insignificant extra solution activity for displaying data, see MPEP 2106.05(d) and are WURC.
Regarding the remark that the configuring and rendering limitations are similar to Example 37 of the 2019 PEG, the examiner would like to point out that the examples are different and the current application merely changes the configuration on the backend with respect to which option do display on the frontend. Where the installation and/or the request to install are not actively performed and rather just options rendered on a display. Thus, the examiner believes the invention is still recited at a high level and not integrated into a practical application nor significantly more than the judicial exception.
Response to 103 arguments
Applicant’s arguments with respect to claim(s) 1-6, 8, 10, 13-18 and 21-24 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument and/or has been cured by additional references.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Noor Alkhateeb whose telephone number is (313)446-4909. The examiner can normally be reached Monday-Friday from 9:00AM ET to 5:00PM ET.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Chat do, can be reached at telephone number (571) 272-3721. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center and the Private Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from Patent Center or Private PAIR. Status information for unpublished applications is available through Patent Center or Private PAIR to authorized users only. Should you have questions about access to Patent Center or the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/NOOR ALKHATEEB/Primary Examiner, Art Unit 2193
Prosecution Insights