DETAILED ACTION
20Notice 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 .
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 3, 8, 11-12, 14, and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable in view of US 20200389317 A1 (Hereinafter referred to as Dunjic), US 20220188129 A1 (Hereinafter referred to as Kotov), and US 20240168752 A1 (Hereinafter referred to as Riscutia).
Regarding claim 1, Dunjic teaches:
A method comprising: applying a management application to a user profile of a user and an identifier of a third-party application hosted by a remote computing system to generate an object notation data structure that stores data related to the third-party application and the user profile (Para. [28-29], Dunjic shows the consent document may reflect a selective grant by user 101, to executed third-party application 108, or to executed access management widget 110 acting on behalf of third-party application 108, of access to specific types or classes of confidential data maintained within confidential data store 136, such as, but not limited to, profile data, account data, or transaction data maintained on behalf of user 101 by computing system. As described herein, the consent document consent document may be formatted in JavaScript Object Notation (JSON) format or another language-independent, data interchange format); applying the management application to the object notation data structure to identify a local software module associated with the third-party application, wherein the local software module is programmed to coordinate communication between the local software module and the third-party application (Fig. 1 (107, 110, 102), Para. [29-30], Dunjic shows the consent document may also identify a permission granted by user 101 to third-party application 108, or to access management widget 110 acting on behalf of third-party application 108, to further process one or more the accessed elements (or types or classes of elements) of confidential data, to locally maintain one or more of the accessed elements (or types or classes of elements) of confidential data, or to further distribute one or more accessed elements (or types or classes of elements) of confidential data to additional related or unrelated computing systems or to application programs executed by these additional or unrelated systems (e.g., fourth- and fifth-party applications, etc.). As described herein, the consent document consent document may be formatted in JavaScript Object Notation (JSON) format or another language-independent, data interchange format. When executed by the one or more processors of computing system 130, authorization engine 152 can perform operations that, in conjunction with access management widget 110 executed at client device);
Dunjic does not disclose:
receiving a configuration file from an integration service programmed to interface with the remote computing system;
applying the management application to the configuration file and the local software module to generate a reconfigured software module that is programmed to facilitate communication between a local program and the third-party application;
applying the reconfigured software module to the object notation data structure to generate a reconfigured object notation data structure;
and applying the management application to the reconfigured object notation data structure to modify a user interface of the local program to include a widget operable to control, via the integration service, the third-party application hosted by the remote computing system.
However, in the analogous art of integration in user interfaces, Kotov teaches:
receiving a configuration file from an integration service programmed to interface with the remote computing system (Para. [82], Kotov shows The fragment configuration module 206 of some embodiments may configure the selected fragment modules 406-414 for rendering on the user interface 400. In some embodiments, the fragment configuration module 206 may configure the fragment modules 406-414 by providing one or more input parameters to each of the fragment modules 406-414. The input parameters may indicate an identity of the user interface 400 on which they are to be rendered (e.g., the homepage of the website, etc.), an account identifier of the user account, and other input values that may specify various aspects of the appearance of the fragment modules, such as a font type, a font size, a font color, a background color, a size, a title, a location of the fragment modules, etc., such that the fragment modules Para. [71], Kotov shows the integration module 132 includes an integration manager 202, a user interface module 204, a fragment configuration module 206, an event handling module 208, and a fragment selection module 210. In some embodiments, the integration module 132 may have access to fragment modules, such as fragment modules 222, 224, 232, 234, etc. for integration into various user interfaces. As discussed herein, each fragment module may be developed independently as a standalone application for performing a function, a service, or part of a service. Each fragment module may developed to include a set of user interface elements (e.g., text, input elements such as input box, radial button, image capturing module, voice capturing module, etc.), a processing component for performing one or more backend functions (e.g., performing a database query, transmitting data via a network to a remote device, etc.), and a set of presentation elements.);
applying the management application to the configuration file and the local software module to generate a reconfigured software module that is programmed to facilitate communication between a local program and the third-party application (Para. [71], Kotov shows The integration module 132 includes an integration manager 202, a user interface module 204, a fragment configuration module 206, an event handling module 208, and a fragment selection module 210. In some embodiments, the integration module 132 may have access to fragment modules, such as fragment modules 222, 224, 232, 234, etc. for integration into various user interfaces. As discussed herein, each fragment module may be developed independently as a standalone application for performing a function, a service, or part of a service. Each fragment module may developed to include a set of user interface elements (e.g., text, input elements such as input box, radial button, image capturing module, voice capturing module, etc.), a processing component for performing one or more backend functions (e.g., performing a database query, transmitting data via a network to a remote device, etc.), and a set of presentation elements. For example, a menu bar fragment module may be configured to display a set of menu items for redirecting the user to different webpages of a website. A recent transaction fragment module may be configured to retrieve transaction data associated with transactions recently conducted through a user account and present the transaction data on a user interface. The presentation may also be interactive, such that the user may select individual transactions from the presentation, and the recent transaction fragment module may then present detail information related to the selected transaction(s). For ease of development and management of these fragment modules, different fragment modules may be developed and/or managed by different groups of people (e.g., different teams within an organization, different organizations, etc.). Para. [77], Kotov shows The fragment configuration module 206 may configure the fragment modules based on the requested user interface.);
In addition, in the analogous art of service integration, Riscutia teaches:
applying the reconfigured software module to the object notation data structure to generate a reconfigured object notation data structure (Para. [43], Riscutia shows third-party extension views are defined by view definitions which are provided in a structured file format, such as JavaScript Object Notation (JSON). The view definition defines the data from the third-party service to be displayed in the UI element, one or more UI elements for displaying the data, one or more actions to be performed on the data, one or more UI controls for causing the actions to be performed on the data, etc. The third-party extension module 214 receives view definitions and is configured to create and render third-party extension views in the user interface 204 of the host application 202 based on the view definitions);
and applying the management application to the reconfigured object notation data structure to modify a user interface of the local program to include a widget operable to control, via the integration service, the third-party application hosted by the remote computing system (Para. [41], Riscutia shows to implement the second mode of integration, the multi-mode in-context service integration system 200 includes a third-party extension module 214 that enables user interface (UI) snippets (e.g., cards, gadgets, widgets, etc.) provided by third-party extensions to be incorporated into the host application 202. For example, third-party extensions implemented by the third-party service or other parties associated with the third-party service can design UI snippets that enable predetermined interactions with the third-party service with which it is associated. For example, a UI snippet may be configured to retrieve and display certain data/content from the third-party service, enable a search of the data/content of the third-party service, add/delete data/content from the third-party service, and the like. Para. [43], third-party extension views are defined by view definitions which are provided in a structured file format, such as JavaScript Object Notation (JSON). The view definition defines the data from the third-party service to be displayed in the UI element, one or more UI elements for displaying the data, one or more actions to be performed on the data, one or more UI controls for causing the actions to be performed on the data, etc. The third-party extension module 214 receives view definitions and is configured to create and render third-party extension views in the user interface 204 of the host application 202 based on the view definitions).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Kotov into the teachings of Dunjic to implement “receiving a configuration file from an integration service programmed to interface with the remote computing system; applying the management application to the configuration file and the local software module to generate a reconfigured software module that is programmed to facilitate communication between a local program and the third-party application. The modification would have been obvious as one of ordinary skill in the art would be motivated as "the integration module 132 may advantageously integrate fragment modules associated with different organizations to be included within a single user interface for the service provider server" (Kotov, Para. [70]).
Additionally, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Riscutia into the teachings of Dunjic to implement "applying the reconfigured software module to the object notation data structure to generate a reconfigured object notation data structure; and applying the management application to the reconfigured object notation data structure to modify a user interface of the local program to include a widget operable to control, via the integration service, the third-party application hosted by the remote computing system". The modification would have been obvious as one of ordinary skill in the art would be motivated "rendering the data connection views in the same style as the host application enables data from third-party services to be integrated seamlessly which can enhance the user experience and promote engagement with the host application and/or third-party service" (Riscutia, Para. [40]).
Regarding claim 3, Dunjic as modified teaches claim 1 as cited above and teaches:
calling an application programming interface (API) stored in the local software module, wherein the API is programmed to interface with the integration service (Para. [35], Dunjic shows executed access management widget 110 may perform operations that establish a secure channel of communications with a programmatic interface established and maintained by computing system 130, e.g., application programming interface (API) 204. Based on the established communications channel, executed access management widget 110 may perform any of the exemplary processes described herein that, in conjunction with an authorization engine executed by computing system 130 (e.g., authorization engine 142), initiate, implement, and manage one or more of the exemplary token-based authentication and consent protocols described herein).
Regarding claim 8, Dunjic as modified teaches claim 1 as cited above, but does not disclose:
selecting, from among a plurality of local software modules stored in a data repository, the local software module, wherein the local software module is uniquely associated with the third-party application.
However, in the analogous art of integration in user interfaces, Kotov teaches:
selecting, from among a plurality of local software modules stored in a data repository, the local software module, wherein the local software module is uniquely associated with the third-party application (Para. [77], Kotov shows The fragment configuration module 206 may configure the fragment modules based on the requested user interface. For example, the fragment configuration module 206 may provide each of the fragment modules a set of input parameters. The set of input parameters may specify one or more aspects of the appearance of the fragment modules when they are rendered on the user interface (e.g., font size attributes, font color attributes, spacing attributes, background attributes, a size of the rendering, a location of the fragment module within the user interface, etc.) such that the look and feel of the fragment modules 222, 224, 232, and 234 are consistent with each other and with the user interface on which they are rendered).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Kotov into the teachings of Dunjic as modified to implement "selecting, from among a plurality of local software modules stored in a data repository, the local software module, wherein the local software module is uniquely associated with the third-party application. The modification would have been obvious as one of ordinary skill in the art would be motivated "such that the look and feel of the fragment modules 222, 224, 232, and 234 are consistent with each other and with the user interface on which they are rendered" (Kotov, Para. [77]).
With regards to claim 11, it is a method claim having similar limitations as cited in claim 1 above. Thus, claim 11 is also rejected under the same rationale as cited in the rejection of claim 1 above.
With regards to claim 12, it is a system claim having similar limitations as cited in claim 1 above. Thus, claim 12 is also rejected under the same rationale as cited in the rejection of claim 1 above.
With regards to claim 14, it is a system claim having similar limitations as cited in claim 3 above. Thus, claim 3 is also rejected under the same rationale as cited in the rejection of claim 3 above.
With regards to claim 18, it is a system claim having similar limitations as cited in claim 8 above. Thus, claim 18 is also rejected under the same rationale as cited in the rejection of claim 8 above.
Claim(s) 2 and 13 is/are rejected under 35 U.S.C. 103 as being unpatentable in view of US 20200389317 A1 (Hereinafter referred to as Dunjic), US 20220188129 A1 (Hereinafter referred to as Kotov), and US 20240168752 A1 (Hereinafter referred to as Riscutia) in further view of US 20170161973 A1 (Hereinafter referred to as Katta).
Regarding claim 2, Dunjic as modified, teaches claim 1 as cited above but does not disclose:
receiving, from a user, a user login to a local computing system hosting the local program; and applying the management application to the user profile associated with the user login to determine the identifier of the third-party application used by the user and hosted by the remote computing system.
However, in the analogous art of processing requests, Katta teaches:
receiving, from a user, a user login to a local computing system hosting the local program (Para. [34],The authorization subsystem functions to store user account information, such as vehicle identifiers that are associated with each user account, vehicle parameter permission settings (e.g., which vehicle parameters are available to third parties, on a per-vehicle basis), user profiles, user preferences, user credentials (e.g., login information to the system, to a third party application, to an OEM platform, etc.), OEM platform identifiers associated with each user account, and/or other user account information. The authorization subsystem can additionally or alternatively generate, store, and/or transmit any one or more of: third party information, such as authentication codes, access tokens, vehicle permission settings, user account permission settings, vehicle parameter permission settings (e.g., which vehicle parameters the third party has requested or has access to), query rate limits, and/or other third party account information. However, the authorization subsystem can be configured in any suitable manner);
and applying the management application to the user profile associated with the user login to determine the identifier of the third-party application used by the user and hosted by the remote computing system (Para. [35], The management subsystem functions to manage the third party applications that have been connected to the user account, enable the user account to interact with permission settings for the third party applications (e.g., add or drop third party applications connected to the user account, retrieve application secrets, etc.), and/or otherwise interact with the third party applications connected to the user account. An example of a user interface enabling such third party application interaction is shown in FIG. 10. However, the management subsystem can store any other suitable information. In operation, the management subsystem can receive data submitted by the third party (e.g., user information, vehicle assignment information, etc.) and/or user (e.g., permission settings, etc.), create authentication codes, verify authentication codes, create and provide access tokens, and/or perform any other suitable functionality. However, the management subsystem can be configured in any suitable manner).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Katta into the teachings of Dunjic to implement “and applying the management application to the user profile associated with the user login to determine the identifier of the third-party application used by the user and hosted by the remote computing system”. The modification would have been obvious as one of ordinary skill in the art would be motivated " the management subsystem can receive data submitted by the third party (e.g., user information, vehicle assignment information, etc.) and/or user (e.g., permission settings, etc.)" (Katta, Para. [35]).
With regards to claim 13, it is a system claim having similar limitations as cited in claim 2 above. Thus, claim 13 is also rejected under the same rationale as cited in the rejection of claim 2 above.
Claim(s) 4 and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable in view of US 20200389317 A1 (Hereinafter referred to as Dunjic), US 20220188129 A1 (Hereinafter referred to as Kotov), and US 20240168752 A1 (Hereinafter referred to as Riscutia) in further view of US 20220353109 A1 (Hereinafter referred to as Elliott).
Regarding claim 4, Dunjic as modified, teaches claim 1 as cited above, but does not disclose:
wherein the configuration file contains instructions for permitting the local program to configure the third-party application via the integration service.
However, in the analogous art of integration of third-party software, Elliott teaches:
wherein the configuration file contains instructions for permitting the local program to configure the third-party application via the integration service (Para. [105], Elliott shows the standardized build process provides a conformed application programming interface and configuration files. Integrating third-party tags 503 into a large-scale digital platform includes a modular design that permits new third-party software to be added, removed, and changed as needed. The Phase 2 system design shown in FIGS. 2, 5 and 6 provides for central management of third-party software integrations by utilizing AI content controller 501 to provide centralized management and propagate updates across all systems.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Elliott into the teachings of Dunjic to implement “wherein the configuration file contains instructions for permitting the local program to configure the third-party application via the integration service”. The modification would have been obvious as one of ordinary skill in the art would be motivated "to provide centralized management and propagate updates across all systems" (Elliott, Para. [105]).
With regards to claim 15, it is a system claim having similar limitations as cited in claim 4 above. Thus, claim 15 is also rejected under the same rationale as cited in the rejection of claim 4 above.
Claim(s) 5 is/are rejected under 35 U.S.C. 103 as being unpatentable in view of US 20200389317 A1 (Hereinafter referred to as Dunjic), US 20220188129 A1 (Hereinafter referred to as Kotov), and US 20240168752 A1 (Hereinafter referred to as Riscutia) in further view of US 20190391798 A1 (Hereinafter referred to as Farrell).
Regarding claim 5, Dunjic as modified, teaches claim 1 as cited, but does not disclose:
identifying, prior to applying the management application to the user profile of the user and the identifier of the third-party application, the identifier of the third-party application,
wherein identifying is performed by inputting the user profile to a machine learning model and receiving, as output of the machine learning model, the identifier of the third-party application
However, in the analogous art of software deployment, Farrell teaches:
identifying, prior to applying the management application to the user profile of the user and the identifier of the third-party application, the identifier of the third-party application,
wherein identifying is performed by inputting the user profile to a machine learning model and receiving, as output of the machine learning model, the identifier of the third-party application (Para. [40], Farrell shows the deployment tool 220 creates a first plurality of mappings (at block 304). Each mapping represents a profile or digital fingerprint of a computing device included in the first plurality of computing devices, the first software application, and usage of at least one feature of the first software application via the computing device. A mapping may include a profile of a computing device (in terms of hardware, software, or a combination thereof), a user profile or classification (for example, accountant), an identifier of the software application (including an identifier of a specific version of the software application), and usage information of the software application. The deployment tool 220 may use various artificial intelligence (AI) algorithms to create these mappings).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Farrell into the teachings of Dunjic as modified to implement ” identifying, prior to applying the management application to the user profile of the user and the identifier of the third-party application, the identifier of the third-party application, wherein identifying is performed by inputting the user profile to a machine learning model and receiving, as output of the machine learning model, the identifier of the third-party application”. The modification would have been obvious as one of ordinary skill in the art would be motivated "to provide insight to potential users of how easily or efficiently the software can be deployed in particular situations, organizations, or industries" (Farrell, Para. [41]).
Claim(s) 6-7, 9, 17, and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable in view of US 20200389317 A1 (Hereinafter referred to as Dunjic), US 20220188129 A1 (Hereinafter referred to as Kotov), and US 20240168752 A1 (Hereinafter referred to as Riscutia) in further view of US 10956179 B1 (Hereinafter referred to as Moturu).
Regarding claim 6, Dunjic as modified teaches claim 1 as cited above, but does not disclose:
wherein the local software module is associated only with the third-party application.
However in the analogous art of third party integration of plugins, Motoru teaches:
wherein the local software module is associated only with the third-party application (Col [12] lines [26-39], Motoru shows each plugin (e.g., 242 or 252) may include two parts: a configuration and one or more widgets. The configuration generally identifies the widgets included in the plugin, a code contract, permissions, the behavior of the plugin, and intended interactions with other widgets or an application (e.g., application 122 in FIG. 1). In some embodiments, legacy code components (e.g., native code components that were created for previous versions of a software product and are intended to be reused in a cross-platform application) and third-party components (e.g., extensions to an application) may be included in a plugin to be compatible with the platform. The user interfaces associated with legacy components or third-party components).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Motoru into the teachings of Dunjic as modified to implement "wherein the local software module is associated only with the third-party application. The modification would have been obvious as one of ordinary skill in the art would be motivated as "the application logic is not tied to the particular platform, the application logic may be deployed dynamically to different types of devices through platform-specific user interfaces and enable a user to leverage the application logic in a more flexible fashion" (Motoru, Col. [9] lines [43-47]).
Regarding claim 7, Dunjic as modified teaches claim 1 as cited above, but does not disclose:
selecting, from among a plurality of local software modules stored in a data repository, the local software module,
wherein the local software module is uniquely associated with the third-party application
However in the analogous art of third party integration of plugins, Motoru teaches:
selecting, from among a plurality of local software modules stored in a data repository, the local software module (Col [5] lines [28-33], Motoru shows computing system 100 includes a client device 120, a server computer 130, an application server 140, a plugin definition repository 150, a widget repository 160, a user interface (UI) component repository 170, and an application logic repository 180, connected via network 110),
wherein the local software module is uniquely associated with the third-party application (Col [12] lines [27] - Col. [13] line [4], Motoru shows plugins 242 and 252 may be modular, self-contained software components of an application that expose specific features of the application. Examples of plugins may include navigation bars that allow a user to move between different steps of a workflow executed within the application 122, progress bars that display an amount of the workflow that a user has completed (and correspondingly an amount of the workflow that remains to be completed), application-specific features, features that leverage hardware present on the computing device on which the application 122 is executing (e.g., image capture using one or more cameras integrated into a client device, authentication using one or more biometric data capture devices integrated into a client device, etc.). Because each plugin may be self-contained, applications may be decomposed into a plurality of independently maintainable components (i.e., independently debugged, updated, extended, etc.).Each plugin (e.g., 242 or 252) may include two parts: a configuration and one or more widgets. The configuration generally identifies the widgets included in the plugin, a code contract, permissions, the behavior of the plugin, and intended interactions with other widgets or an application (e.g., application 122 in FIG. 1). In some embodiments, legacy code components (e.g., native code components that were created for previous versions of a software product and are intended to be reused in a cross-platform application) and third-party components (e.g., extensions to an application) may be included in a plugin to be compatible with the platform. The user interfaces associated with legacy components or third-party components may be implemented as a widget that can be loaded into a shell 210, 220, and/or 230. Each plugin (e.g., 242 and 252) and widget (e.g., 244 and 254) may be registered in a central configuration service, such as plugin registry 260. Plugin registry 260 represents a centrally managed service that manages the plugin configurations that may be used by applications hosted in shells 210, 220, or 230 to provide customized user experiences based on, for example, preferences of the user, a geographic location of the client device, a language currently used by the application, etc. The plugin registry 260 generally is responsible for delivering applicable configuration data for a specific application. By registering plugins in plugin registry 260, and by defining plugins as a configuration and a plurality of widgets, different versions of a cross-platform application may be supported by various platforms. For example, an application deployed via web shell 220 and/or native desktop shell 230 may integrate cross-platform user interface generation tools, JavaScript libraries, such as Dojo, JQuery, or Angular, and other technologies which can be leveraged to deploy a web-based version of a cross-platform user interface, regardless of whether the user interface is being deployed in a web browser or a native application that includes a web browser component. Similarly, an application deployed via mobile shell 210 may integrate cross-platform user interface generation tools, native code components (e.g., Java components for applications deployed on Android devices or Objective C components for applications deployed on mobile device operating systems, such as iOS, Android, Windows Mobile, at the like), and other technologies that can be leveraged to deploy a native mobile version of the cross-platform user interface.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Motoru into the teachings of Dunjic as modified to implement "selecting, from among a plurality of local software modules stored in a data repository, the local software module, wherein the local software module is uniquely associated with the third-party application". The modification would have been obvious as one of ordinary skill in the art would be motivated as "the application logic is not tied to the particular platform, the application logic may be deployed dynamically to different types of devices through platform-specific user interfaces and enable a user to leverage the application logic in a more flexible fashion" (Motoru, Col. [9] lines [43-47]).
Regarding claim 9, Dunjic as modified teaches claim 1 as cited above, but does not disclose:
wherein applying the management application to the configuration file and the local software module to generate the reconfigured software module comprises: adding an application programming interface (API) received in the configuration file to the local software module.
However in the analogous art of third party integration of plugins, Motoru teaches:
wherein applying the management application to the configuration file and the local software module to generate the reconfigured software module comprises: adding an application programming interface (API) received in the configuration file to the local software module (Col. [12] lines [26-28], Motoru shows each plugin (e.g., 242 or 252) may include two parts: a configuration and one or more widgets. Col. [7] lines [50-57], Motoru shows the plugin may identify included widgets, functions the plugin can invoke in the API service 136, permissions associated with the plugin, behaviors of the plugin, intended interactions with other parts of a service, such as API service 136, and the like. Each plugin may be versioned as the widget definitions and/or application logic associated with a plugin is updated).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Motoru into the teachings of Dunjic as modified to implement "wherein applying the management application to the configuration file and the local software module to generate the reconfigured software module comprises: adding an application programming interface (API) received in the configuration file to the local software module". The modification would have been obvious as one of ordinary skill in the art would be motivated as "the widget API provides a centralized API that can be used by different applications executing on different platforms" (Motoru, Col. [4] lines [60-62]).
With regards to claim 17, it is a system claim having similar limitations as cited in claim 7 above. Thus, claim 17 is also rejected under the same rationale as cited in the rejection of claim 7 above.
With regards to claim 19, it is a system claim having similar limitations as cited in claim 9 above. Thus, claim 19 is also rejected under the same rationale as cited in the rejection of claim 9 above.
Claim(s) 10 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable in view of US 20200389317 A1 (Hereinafter referred to as Dunjic), US 20220188129 A1 (Hereinafter referred to as Kotov), and US 20240168752 A1 (Hereinafter referred to as Riscutia) in further view of US 20060242248 A1 (Hereinafter referred to as Kokkinen).
Regarding claim 10, Dunjic as modified teaches claim 1 as cited above, but does not disclose:
wherein applying the management application to the configuration file and the local software module to generate the reconfigured software module comprises: adding an executable file stored in the configuration file to the local software module.
However in the analogous art of shortcut generator, Kokkinen teaches:
wherein applying the management application to the configuration file and the local software module to generate the reconfigured software module comprises: adding an executable file stored in the configuration file to the local software module (Para. [32], Kokkinen shows the mobile station 10 includes in a memory device 10f the user interface application 10c and possibly also the configuration file 10d. The user interface application 10c and possibly also the configuration file 10d provide/implement what are here called and indicated as executable shortcuts 10g to respective services available via the message center. The shortcuts 10g are executable in that the user "points and shoots," i.e. selects and executes by e.g. pressing a key on the keypad predetermined to cause a message bearing a request associated with the shortcut to be sent to the content provider via the message center).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Kokkinen into the teachings of Dunjic as modified to implement “wherein applying the management application to the configuration file and the local software module to generate the reconfigured software module comprises: adding an executable file stored in the configuration file to the local software module”. The modification would have been obvious as one of ordinary skill in the art would be motivated "for enabling the user to access the selected service" (Kokkinen, Para. [9).
With regards to claim 20, it is a system claim having similar limitations as cited in claim 10 above. Thus, claim 20 is also rejected under the same rationale as cited in the rejection of claim 10 above.
Claim(s) 16 is/are rejected under 35 U.S.C. 103 as being unpatentable in view of US 20200389317 A1 (Hereinafter referred to as Dunjic), US 20220188129 A1 (Hereinafter referred to as Kotov), and US 20240168752 A1 (Hereinafter referred to as Riscutia) in further view of US 20230022845 A1 (Hereinafter referred to as Meng) and US 20190391798 A1 (Hereinafter referred to as Farrell).
Regarding claim 16, Dunjic as modified teaches claim 1 as cited above, but does not disclose:
wherein applying the management application comprises to a machine learning model and generating, as output, the identifier of the third-party application
providing the object notation data structure as input to a machine learning model
However in the analogous art of software deployment, Farrell teaches:
wherein applying the management application comprises to a machine learning model and generating, as output, the identifier of the third-party application (Para. [40], Farrell shows the deployment tool 220 creates a first plurality of mappings (at block 304). Each mapping represents a profile or digital fingerprint of a computing device included in the first plurality of computing devices, the first software application, and usage of at least one feature of the first software application via the computing device. A mapping may include a profile of a computing device (in terms of hardware, software, or a combination thereof), a user profile or classification (for example, accountant), an identifier of the software application (including an identifier of a specific version of the software application), and usage information of the software application. The deployment tool 220 may use various artificial intelligence (AI) algorithms to create these mappings.)
Additionally, in the analogous art of information retrieval, Meng teaches:
providing the object notation data structure as input to a machine learning model (Para. [112], Meng shows the JSON output also contains larger semantic structures (e.g., phrases, paragraphs, blocks) as well as smaller segments, such as letters and break types (e.g., spaces, tabs, etc.). This output JSON is also the input for one or more machine learning models)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Farrell into the teachings of Dunjic as modified to implement ”wherein applying the management application comprises to a machine learning model and generating, as output, the identifier of the third-party application”. The modification would have been obvious as one of ordinary skill in the art would be motivated "to provide insight to potential users of how easily or efficiently the software can be deployed in particular situations, organizations, or industries" (Farrell, Para. [41]).
In addition, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Meng into the teachings of Dunjic as modified to implement “providing the object notation data structure as input to a machine learning model”. The modification would have been obvious as one of ordinary skill in the art would be motivated as JSON, can be used as input for other machine learning models, such as Convolutional .
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20110119603 A1 – This prior art shows using a composite GUI to integrate a plurality of applications
US 20200133982 A1 – This prior art shows integrating applications into a management dashboard with widgets
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZEERICK A MALIK whose telephone number is (571)272-8110. The examiner can normally be reached Mon-Thurs, 7-5.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Chat Do can be reached at (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 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.
/Z.A.M./Examiner, Art Unit 2193
/Chat C Do/Supervisory Patent Examiner, Art Unit 2193
Prosecution Insights