DETAILED ACTION
This action is in response to communication filed on 26 June 2026. Claims 1-20 are pending in the application and have been considered below.
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 .
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claim 20 is rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the enablement requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to enable one skilled in the art to which it pertains, or with which it is most nearly connected, to make and/or use the invention. Claim 20 recites “a graphical element of the set of graphical elements in the rule suggestion interface includes a list picker element including the list of candidate values” (emphasis added). “a list picker element” is not recited in the specification. For the purpose of prosecution, Examiner is interpreting “a list picker element” to be the same as item 416 in fig. 4D, for example.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3, 5-7, 15-17 and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over DASDAN et al. (US20230101588A1) in view of ROVITO et al. (US20180063150A1).
As to claim 1, DASDAN teaches:
a computer-implemented method for automation rule creation within a content collaboration platform (see figs. 1-10, par. 0039, wherein the profiles service 114 can include information about users of the collaboration system 100. The profile service 114 can identify a customer, such as an organization that utilizes the collaboration platform 100 and provide the collaboration platform 100 for members of the organization. The profiles service 114 can also include profile information for members of the organization such as usernames, authentication credentials, email addresses, team associations, organizational roles; as taught by DASDAN),
causing generation of a graphical user interface of the content collaboration platform (see figs. 3A-3C, par. 0060, wherein FIG. 3A shows an example user interface 300 for a collaboration system, such as the collaboration system 100 described herein. The user interface 300 can include one or more regions or panes that are used to display graphical objects and other information to a user and can include various interface elements that can be selected by a user to perform different functions. For example, the user interface 300 can include a navigation pane 302 that displays graphical objects that are associated with documents hosted by the collaboration system. The user interface 300 can also include a content pane 304 that includes content associated with a particular document, content page, or other content, all of which are referred to herein generically as a document; as taught by DASDAN),
the graphical user interface including an editor panel configured to receive user-generated content for an electronic document (see figs 3A-3D, par. 0064, wherein FIG. 3C shows an example of an automation editor 320 that can be used to generate an automation rule for documents hosted by the collaboration system. The automation editor 320 can be launched in response to determining a change to the hierarchical structure of one or more graphical objects as described herein. This can include changing the nodal structure that is used to organize the graphical objects in the user interface, archiving documents, removing documents, displaying documents in different sub-spaces and so on; as taught by DASDAN)
and a navigation panel displaying a hierarchical element tree having a set of elements selectable to cause display of a respective electronic document (see figs. 3A-3D, par. 0061, wherein the navigation pane 302 can be organized in a variety of ways. In some cases, as illustrated in FIG. 3A, the navigation pane 302 can have a nodal hierarchical structure that displays references to documents according to their dependent relationships. For example, a first level hierarchical structure can include a space 310, which may be a collection of documents that have a common criteria; as taught by DASDAN);
in response to a first user input to the graphical user interface, the first user input configured to initiate an action associated with an action type (see par. 0020, wherein in some cases, an automation can be created and suggested based on a type of content item the user is creating, a group or team associated with content item(s) and so on. In other cases, an automation can be created and/or suggested based on a type of action a user is performing. This can include tracking and analyzing a user's previous interactions with the service, or program to identify high frequency tasks, or other tasks routinely performed by a user. For example, a series or user event logs or other user interaction records may be analyzed in order to determine a proposed automation rule that is to presented to the user; as taught by DASDAN);
determine whether a system use condition associated with the authenticated user satisfies a prompt criteria (see par. 0045, wherein the collaboration system can track user interactions associated with specific documents, which can include an access count that tracks a number of times a graphical object is accessed by various users of the systems, various types of interactions with data such as views, comments, edits or other interactions, time spent interacting with documents, and so on. In some cases, the collaboration system stores these interactions as metadata for the corresponding document. In this regard, the collaboration system can develop historical data sets for documents hosted by the system. In other cases, the collaboration system can prompt or otherwise receive a rating for particular documents, which can be used to determine a popularity, usefulness, quality or other metric for an associated document; see also par. 0072, wherein in some cases, the editable interface is based on information about a particular user. For example, the collaboration system may use information about particular user that is stored in customer profile service 114 to determine the type of information to provide in the editable interface. In this regard, a user with an information technology (IT) profile may be provided with the code for implementing the rule, while a user in the business department may be provided with pre-defined input fields (e.g., sliders); as taught by DASDAN);
in accordance with the system use condition satisfying the prompt criteria, select an automation rule template corresponding to the action type (see par. 0042, wherein the recommendation engine 120 can analyze user interactions with the collaboration system, analyze history data such as stored at data platform, or analyze other data to derive automations for recommending to users of the system. The recommendation engine 120 can used event logs, user profiles and/or associated data, contextual data, and/or the like for generating information. For example, the recommendation engine 120 can track how users interact with the system and analyze this data to generate automation rules that can be proposed to users of the system. In some cases, the recommendations may be in the form of a document, such as a template for presenting content at the collaboration system 100; as taught by DASDAN),
the automation rule template configured to generate an automation rule that automatically initiates future actions associated with the action type (see par. 0098, wherein in some cases, the automation rule can be derived from the action that was performed by the user. For example, in the case of a user forwarding a particular type of content to a group of users, the automation rule can be generated to perform this task automatically; see also par. 0041, wherein the automation engine 118 can implement rules in a variety of ways including scheduling rules to execute on documents and/or other content items at defined intervals, under conditions associated with a particular rule; as taught by DASDAN);
cause display of a rule suggestion interface, the rule suggestion interface having a set of graphical elements, each respective graphical element of the set of graphical elements corresponding to a respective automation component of the automation rule template (see fig. 5, par. 0077, wherein the automation editor 506 can be launched in response to a user selecting an option to modify an automation such as described herein. In other cases, the automation editor 506 can be automatically included as part of the rule being proposed to a user. The automation editor 506 can include an editable interface 508 that has fields 510 that can be modified by a user. The fields 510 can include parameters that affect the application of the proposed automation rule. For example, the fields 510 can include an editable parameter for modifying a condition for applying the rule to a document; as taught by DASDAN);
in response to a second user input provided to the rule suggestion interface, assigning a value to an instance of an automation component associated with a graphical element of the set of graphical elements (see figs. 3A-3D and 5, par. 0057, wherein in some cases, the automation rule includes editable fields that are pre-populated with values that are determined by the collaboration system (e.g., automation engine 118 and/or recommendation engine 120), but allows these fields to be modified by the user; see also par. 0077, wherein the automation editor 506 can be launched in response to a user selecting an option to modify an automation such as described herein. In other cases, the automation editor 506 can be automatically included as part of the rule being proposed to a user. The automation editor 506 can include an editable interface 508 that has fields 510 that can be modified by a user. The fields 510 can include parameters that affect the application of the proposed automation rule. For example, the fields 510 can include an editable parameter for modifying a condition for applying the rule to a document (e.g., [CONDITION] field), an editable parameter for modifying an action associated with the automation rule (e.g., [ACTION] field) and an editable parameter for modifying documents that the automation rule is applied to (e.g., [DOCUMENT(S)] field). The editable interface 508 can include other editable parameters, which can be proposed by the automation rule or added by the user in the user interface; as taught by DASDAN);
and in response to a third user input, cause creation of a new automation rule, the new automation rule having a set of automation components corresponding to the set of graphical elements of the rule suggestion interface, wherein the new automation rule includes the instance of the automation component having the assigned value (see par. 0078, wherein the user interface can also include a first user interface element 512 for accepting the modifications to the automation rule. In some cases, accepting the modifications can result in the rule being applied to documents hosted by the collaboration system. In other cases, accepting the modifications can show a preview of the effect of the rule as described here; as taught by DASDAN).
DASDAN does not expressly teach the method comprising: authenticating a user with respect to an instance of a content collaboration platform.
In similar field of endeavor, ROVITO teaches the method comprising: authenticating a user with respect to an instance of a content collaboration platform (See figs. 2-10, par. 0052, wherein as shown in FIG. 2, a user of the client device 70 can seek access to the automation environment 20 by transmitting user credentials to the automation environment 20 via the network 40, for example (see FIG. 1). The user credentials can include a username and password, token, or other means of authenticating the user of the client device 70; see also par. 0053; wherein in turn, the interface access engine 23 can authenticate and verify the identity of the user of the client device 70 based on a comparison between the user credentials received from the client device 70 and data stored in the user accounts 26; see also par. 0054; wherein once the user of the client device 70 is identified, the interface access engine 23 can proceed to evaluate the access control rules 27 as they apply to the user; see also fig. 3, par. 0068, wherein at step 308, the process includes the interface access engine 23 identifying the rights of the user of the client device 70 to access certain functions of certain automation devices; as taught by ROVITO).
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 DASDAN apparatus to include the teachings of ROVITO wherein the method comprising: authenticating a user with respect to an instance of a content collaboration platform. Such a person would have been motivated to make this combination as it is advantageous to control permissions for the user access based on a number of criteria. To that end, the interface access engine 23 is configured to assist the interface engine 21 with the evaluation of user credentials, status data, and other data against the access control rules 27 and the roles and permissions 28. For example, the interface access engine 23 is configured to perform user authentication and/or identification before any given user is permitted access to the management engine 22. The interface access engine 23 is also configured to evaluate user credentials, status data, and other data against the access control rules 27 and the roles and permissions 28. The interface engine 21 can then enable or disable certain features or functions of the automation devices 60-63, among others, based on the evaluation performed by the interface access engine 23 (see ROVITO, fig. 1, par. 0024).
As to claim 2, DASDAN and ROVITO teach the limitations of claim 1. DASDAN further teaches wherein: the automation component is a first automation component; the new automation rule includes a second automation component defining a text input criteria; and the method further comprises, in response to detecting that an event occurring within the content collaboration platform satisfies the trigger criteria, executing the new automation rule (see fig. 3C, par. 0065, wherein the automation editor 320 can include a rule explanation field 322, a first user interface element 324 for accepting the rule (e.g., accept button), a second user interface element 326 for modifying the rule (e.g., Modify button) and a third user interface element 328 for declining the rule (e.g., decline button). In some embodiments the rule explanation field 322 can include a natural language explanation of the rule, which can include the conditions that trigger application of the rule and the actions that occur as a result. Additionally or alternatively, the rule explanation field 322 can include pseudocode which can include Boolean operators, logical operators, arithmetic operators, and/or the like; as taught by DASDAN).
As to claim 3, DASDAN and ROVITO teach the limitations of claim 2. DASDAN further teaches wherein: the action initiated by the first user input includes a content item operation with respect to a first content item; and a third automation component of the new automation rule is configured to initiate the content item operation with respect to a second content item different from the first content item (see figs. 3C-3D, par. 0023, wherein the automation rule can include an explanation of the conditions that would trigger the rule, the actions associated with the rule, and identify a set of documents that would be affected by the rule. In some cases, presenting the automation rule in a user interface can include generating a preview of the effect of the rule on the documents. In response to a user accepting the automation rule, the collaboration system can execute the actions of the rule to the affected documents. For example, an automation rule can specify that all documents that are below a defined access count (e.g., infrequently accessed) are to be archived. In response to the user accepting the automation rule, the collaboration system can archive documents meeting the archiving condition. In some embodiments, displaying an automation rule to a user can include providing the user an option to modify the rule. Accordingly, the user may be able to change one or more parameters of the rule to change the set of documents affected by the rule; as taught by DASDAN).
As to claim 5, DASDAN and ROVITO teach the limitations of claim 1. ROVITO further teaches wherein the second user input corresponds to a user selection of the value from a list of candidate values, the list of candidate values displayed in association with the graphical element of the automation component (see par. 0074, wherein FIGS. 4-11 illustrate example user interfaces generated by the automation environment 20 shown in FIG. 1. The user interfaces are not exhaustive but illustrate a number of different examples. FIG. 4 illustrates an example user interface for managing rental units (also “units”). In this embodiment, the interface access engine 23 has determined that a user account with the role of property manager should be provided a list of units. This list would not, for example, be provided to a user account with the role of resident. The property manager is thus able to see a list of units, the vacancy status of those units, assigned staff members, and the automation settings of one or more automation devices at each unit (among potentially other information); see also fig. 7, par. 0077; as taught by ROVITO).
As to claim 6, DASDAN and ROVITO teach the limitations of claim 5. ROVITO further teaches wherein the list of candidate values comprises a list of user identifiers, the list of user identifiers corresponding to users of the content collaboration platform (see par. 0076, wherein FIGS. 6-8 illustrate example user interfaces for managing residents, guest residents, maintenance (e.g., staff), leasing agents, vendors, door code guests, and other users. Referring to FIG. 6, an example user interface to manage residents' access to the system is shown. Property managers can use this interface to add and onboard (e.g., manage) residents, grant and revoke users access to the automation capabilities in certain dwellings, grant and revoke user access to control the automation capabilities in certain dwellings, and control the automation capabilities in certain dwellings; see also fig. 7, par. 0077; as taught by ROVITO).
As to claim 7, DASDAN and ROVITO teach the limitations of claim 5. DASDAN further teaches in response to selecting the automation rule template and in accordance with a determination that a particular automation component of the automation rule template is associated with a third-party service, sending a request to the third-party service requesting the list of candidate values; and receiving, from the third-party service, the list of candidate values for display in the rule suggestion interface (see par. 0121, wherein the various functions and operations of a system such as described herein can be implemented in a number of suitable ways, developed for leveraging any number of suitable libraries, frameworks, first or third-party APIs, local or remote databases; as taught by DASDAN).
As to claim 15, DASDAN teaches:
a computer-implemented method for automation rule creation within a content collaboration platform (see figs. 1-10, par. 0039, wherein the profiles service 114 can include information about users of the collaboration system 100. The profile service 114 can identify a customer, such as an organization that utilizes the collaboration platform 100 and provide the collaboration platform 100 for members of the organization. The profiles service 114 can also include profile information for members of the organization such as usernames, authentication credentials, email addresses, team associations, organizational roles; as taught by DASDAN),
causing generation of a graphical user interface of the content collaboration platform (see figs. 3A-3C, par. 0060, wherein FIG. 3A shows an example user interface 300 for a collaboration system, such as the collaboration system 100 described herein. The user interface 300 can include one or more regions or panes that are used to display graphical objects and other information to a user and can include various interface elements that can be selected by a user to perform different functions. For example, the user interface 300 can include a navigation pane 302 that displays graphical objects that are associated with documents hosted by the collaboration system. The user interface 300 can also include a content pane 304 that includes content associated with a particular document, content page, or other content, all of which are referred to herein generically as a document; as taught by DASDAN),
the graphical user interface including an editor panel configured to receive user-generated content for an electronic document (see figs 3A-3D, par. 0064, wherein FIG. 3C shows an example of an automation editor 320 that can be used to generate an automation rule for documents hosted by the collaboration system. The automation editor 320 can be launched in response to determining a change to the hierarchical structure of one or more graphical objects as described herein. This can include changing the nodal structure that is used to organize the graphical objects in the user interface, archiving documents, removing documents, displaying documents in different sub-spaces and so on; as taught by DASDAN)
and a navigation panel displaying a hierarchical element tree having a set of elements selectable to cause display of a respective electronic document (see figs. 3A-3D, par. 0061, wherein the navigation pane 302 can be organized in a variety of ways. In some cases, as illustrated in FIG. 3A, the navigation pane 302 can have a nodal hierarchical structure that displays references to documents according to their dependent relationships. For example, a first level hierarchical structure can include a space 310, which may be a collection of documents that have a common criteria; as taught by DASDAN);
in response to a first user input to the graphical user interface, the first user input configured to initiate an action associated with an action type (see par. 0020, wherein in some cases, an automation can be created and suggested based on a type of content item the user is creating, a group or team associated with content item(s) and so on. In other cases, an automation can be created and/or suggested based on a type of action a user is performing. This can include tracking and analyzing a user's previous interactions with the service, or program to identify high frequency tasks, or other tasks routinely performed by a user. For example, a series or user event logs or other user interaction records may be analyzed in order to determine a proposed automation rule that is to presented to the user; as taught by DASDAN);
determine whether a system use condition associated with the authenticated user satisfies a prompt criteria (see par. 0045, wherein the collaboration system can track user interactions associated with specific documents, which can include an access count that tracks a number of times a graphical object is accessed by various users of the systems, various types of interactions with data such as views, comments, edits or other interactions, time spent interacting with documents, and so on. In some cases, the collaboration system stores these interactions as metadata for the corresponding document. In this regard, the collaboration system can develop historical data sets for documents hosted by the system. In other cases, the collaboration system can prompt or otherwise receive a rating for particular documents, which can be used to determine a popularity, usefulness, quality or other metric for an associated document; see also par. 0072, wherein in some cases, the editable interface is based on information about a particular user. For example, the collaboration system may use information about particular user that is stored in customer profile service 114 to determine the type of information to provide in the editable interface. In this regard, a user with an information technology (IT) profile may be provided with the code for implementing the rule, while a user in the business department may be provided with pre-defined input fields (e.g., sliders); as taught by DASDAN);
and determine whether a permission level of the authenticated user satisfies a second prompt criteria (see par. 0038, wherein the permissions service 112 can enable which actions a given user may perform with different resources, documents or other information of the collaboration system 100. The permissions service can be used to manage user access to documents such as various spaces and/or pages. For example, a user may be allowed to create, edit, comment and structure documents associated with their own content space, but only be able to read and comment on documents associated created and/or managed by other users. In some cases, the permission service 112 gives different permissions to different users. For example, some user may be assigned administrator privileges, which may give them more access to documents, such as the ability to edit, delete, structure/organize, format, or otherwise manipulate documents for other users of the system. In some cases, the permissions service 112 may manage special permission for specific users and/or other services such as the automations engines that allows operations such as updating hierarchical structures of hosted documents, archiving documents, creating templates and so on, which can include broader system side privileges. Additionally or alternatively, the permissions granted to the automation may correspond to those granted to the user, which may help avoid a permissions breach through the automation system; as taught by DASDAN);
in accordance with a determination that each prompt criteria of a set of prompt criteria is satisfied, the set of prompt criteria including the first prompt criteria and the second prompt criteria (see par. 0051, wherein other types of user inputs can be used to determine whether to change the organizational structure for displayed graphical objects. For example, interactions with documents can be tracked to determine how useful they are to users of the system. This can include prompting users to rate the documents, determining a time of user interaction, whether the users comment on, link to, or otherwise share the document, whether users download or otherwise save an access link to the document and so on; as taught by DASDAN),
select an automation rule template corresponding to the action type (see par. 0042, wherein the recommendation engine 120 can analyze user interactions with the collaboration system, analyze history data such as stored at data platform, or analyze other data to derive automations for recommending to users of the system. The recommendation engine 120 can used event logs, user profiles and/or associated data, contextual data, and/or the like for generating information. For example, the recommendation engine 120 can track how users interact with the system and analyze this data to generate automation rules that can be proposed to users of the system. In some cases, the recommendations may be in the form of a document, such as a template for presenting content at the collaboration system 100; as taught by DASDAN),
the automation rule template configured to generate an automation rule that automatically initiates future actions associated with the action type (see par. 0098, wherein in some cases, the automation rule can be derived from the action that was performed by the user. For example, in the case of a user forwarding a particular type of content to a group of users, the automation rule can be generated to perform this task automatically; see also par. 0041, wherein the automation engine 118 can implement rules in a variety of ways including scheduling rules to execute on documents and/or other content items at defined intervals, under conditions associated with a particular rule; as taught by DASDAN);
cause display of a rule suggestion interface, the rule suggestion interface having a set of graphical elements, each respective graphical element of the set of graphical elements corresponding to a respective automation component of the automation rule template (see fig. 5, par. 0077, wherein the automation editor 506 can be launched in response to a user selecting an option to modify an automation such as described herein. In other cases, the automation editor 506 can be automatically included as part of the rule being proposed to a user. The automation editor 506 can include an editable interface 508 that has fields 510 that can be modified by a user. The fields 510 can include parameters that affect the application of the proposed automation rule. For example, the fields 510 can include an editable parameter for modifying a condition for applying the rule to a document; as taught by DASDAN);
and in response to a second user input, cause creation of a new automation rule, the new automation rule having a set of automation components corresponding to the set of graphical elements of the rule suggestion interface (see par. 0078, wherein the user interface can also include a first user interface element 512 for accepting the modifications to the automation rule. In some cases, accepting the modifications can result in the rule being applied to documents hosted by the collaboration system. In other cases, accepting the modifications can show a preview of the effect of the rule as described here; as taught by DASDAN).
DASDAN does not expressly teach the method comprising: authenticating a user with respect to an instance of a content collaboration platform.
In similar field of endeavor, ROVITO teaches the method comprising: authenticating a user with respect to an instance of a content collaboration platform (See figs. 2-10, par. 0052, wherein as shown in FIG. 2, a user of the client device 70 can seek access to the automation environment 20 by transmitting user credentials to the automation environment 20 via the network 40, for example (see FIG. 1). The user credentials can include a username and password, token, or other means of authenticating the user of the client device 70; see also par. 0053; wherein in turn, the interface access engine 23 can authenticate and verify the identity of the user of the client device 70 based on a comparison between the user credentials received from the client device 70 and data stored in the user accounts 26; see also par. 0054; wherein once the user of the client device 70 is identified, the interface access engine 23 can proceed to evaluate the access control rules 27 as they apply to the user; see also fig. 3, par. 0068, wherein at step 308, the process includes the interface access engine 23 identifying the rights of the user of the client device 70 to access certain functions of certain automation devices; as taught by ROVITO).
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 DASDAN apparatus to include the teachings of ROVITO wherein the method comprising: authenticating a user with respect to an instance of a content collaboration platform. Such a person would have been motivated to make this combination as it is advantageous to control permissions for user access based on a number of criteria. To that end, the interface access engine 23 is configured to assist the interface engine 21 with the evaluation of user credentials, status data, and other data against the access control rules 27 and the roles and permissions 28. For example, the interface access engine 23 is configured to perform user authentication and/or identification before any given user is permitted access to the management engine 22. The interface access engine 23 is also configured to evaluate user credentials, status data, and other data against the access control rules 27 and the roles and permissions 28. The interface engine 21 can then enable or disable certain features or functions of the automation devices 60-63, among others, based on the evaluation performed by the interface access engine 23 (see ROVITO, fig. 1, par. 0024).
As to claim 16, DASDAN and ROVITO teach the limitations of claim 15. DASDAN further teaches
the content collaboration platform is a first software platform; the action type is associated with a second software platform (see fig. 1, items 102-120, par. 0028, wherein FIG. 1 shows an example collaboration system 100 for generating automations for managing documents hosted by the collaboration system 100. The collaboration system 100 can include a user interface (UI) layer 102, a collaboration platform application programming interface (API) 108 and a streaming platform 110; as taught by DASDAN);
the computer-implemented method further comprises, in response to the first user input to the graphical user interface, communicating with the second software platform to determine whether an account status of authenticated user satisfies a third prompt criteria; and the set of prompt criteria further includes the third prompt criteria (see par. 0037, wherein in cases where the collaborations system includes a document management platform, the streaming platform can push documents to the collaboration system and/or pull documents from the collaboration system. In some cases, the streaming platform can allow clients to update (e.g., push or pull) documents in real time. The streaming platform 110 can be designed to notify client devices of update events such as push or pull operations performed on documents; as taught by DASDAN).
As to claim 17, DASDAN and ROVITO teach the limitations of claim 16. DASDAN further teaches wherein the authenticated user satisfies the third prompt criteria if the account status of the authenticated user is associated with a user account of the second software platform (see par. 0037, wherein in some embodiments, the streaming platform 110 can support services such as the permissions service 112, the profiles service 114, the data platform 116, the automation engine 118 and/or the recommendation engine 120; as taught by DASDAN).
As to claim 19, DASDAN and ROVITO teach the limitations of claim 16. DASDAN further teaches
in response to a third user input provided to the rule suggestion interface, assigning a value to an instance of an automation component associated with a graphical element of the set of graphical elements, wherein the new automation rule includes the instance of the automation component having the assigned value (see figs. 3A-3D and 5, par. 0057, wherein in some cases, the automation rule includes editable fields that are pre-populated with values that are determined by the collaboration system (e.g., automation engine 118 and/or recommendation engine 120), but allows these fields to be modified by the user; see also par. 0077, wherein the automation editor 506 can be launched in response to a user selecting an option to modify an automation such as described herein. In other cases, the automation editor 506 can be automatically included as part of the rule being proposed to a user. The automation editor 506 can include an editable interface 508 that has fields 510 that can be modified by a user. The fields 510 can include parameters that affect the application of the proposed automation rule. For example, the fields 510 can include an editable parameter for modifying a condition for applying the rule to a document (e.g., [CONDITION] field), an editable parameter for modifying an action associated with the automation rule (e.g., [ACTION] field) and an editable parameter for modifying documents that the automation rule is applied to (e.g., [DOCUMENT(S)] field). The editable interface 508 can include other editable parameters, which can be proposed by the automation rule or added by the user in the user interface; as taught by DASDAN).
As to claim 20, DASDAN and ROVITO teach the limitations of claim 19. ROVITO further teaches
in response to selecting the automation rule template, sending a request to the second software platform to request a list of candidate values; and receiving, from the second software platform, the list of candidate values for display in the rule suggestion interface (see par. 0074, wherein FIGS. 4-11 illustrate example user interfaces generated by the automation environment 20 shown in FIG. 1. The user interfaces are not exhaustive but illustrate a number of different examples. FIG. 4 illustrates an example user interface for managing rental units (also “units”). In this embodiment, the interface access engine 23 has determined that a user account with the role of property manager should be provided a list of units. This list would not, for example, be provided to a user account with the role of resident. The property manager is thus able to see a list of units, the vacancy status of those units, assigned staff members, and the automation settings of one or more automation devices at each unit (among potentially other information); as taught by ROVITO).
DASDAN further teaches a graphical element of the set of graphical elements in the rule suggestion interface includes a list picker element including the list of candidate values; and the third user input corresponds to a user selection of a value from the list of candidate values (see par. 0072, wherein the field(s) can include options for modifying the proposed action of the rule. For example, in cases of modifying the hierarchy, the action could specify parameters associated with the nodal structure. In further cases, the editable interface can include pseudo-code that can be modified by a user, or the code that will be used to implement the rule; as taught by DASDAN).
Claims 4 and 18 is rejected under 35 U.S.C. 103 as being unpatentable over DASDAN et al. (US20230101588A1) in view of ROVITO et al. (US20180063150A1) and further .
in view of BADAWY et al. (US11196775B1).
As to claim 4, DASDAN and ROVITO teach the limitations of claim 1. DASDAN and ROVITO do not expressly teach wherein the system use condition satisfies the prompt criteria if the user has not created an automation rule instance using the automation rule template within a time window.
In similar field of endeavor, BADAWY teaches wherein the system use condition satisfies the prompt criteria if the user has not created an automation rule instance using the automation rule template within a time window (see fig. 8, col. 35, ll. 1-11, wherein if there is an identity graph available (e.g., if one exists in the graph data store 866 or was created within the time window), the role miner 880 can determine if a scoring attribute was received with the role mining request. If no scoring attribute was received, the available identity graph may be used for role mining. If, however, a scoring attribute was received and an identity graph is available, the existing identity graph can be scoped based on the received scoring attribute and the type of role mining to be performed; as taught by BADAWY).
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 DASDAN and ROVITO apparatus to include the teachings of BADAWY wherein the system use condition satisfies the prompt criteria if the user has not created an automation rule instance using the automation rule template within a time window. Such a person would have been motivated to make this combination as it is advantageous for the user to save time when the system uses a default value for creating or editing an item as a design decision if a response from the user is not received within a preset timeframe.
Claim 18 amounts to a similar method of claim 4. Accordingly, claim 18 is rejected for substantially the same reasons as presented above for claim 4 and based on the references’ disclosure of the necessary supporting hardware and software.
Claims 8 and 12-13 are rejected under 35 U.S.C. 103 as being unpatentable over DASDAN et al. (US20230101588A1) in view of PONNAN et al. (US20180004545A1).
As to claim 8, DASDAN teaches:
a computer-implemented method for automation rule creation within a content collaboration platform (see figs. 1-10, par. 0039, wherein the profiles service 114 can include information about users of the collaboration system 100. The profile service 114 can identify a customer, such as an organization that utilizes the collaboration platform 100 and provide the collaboration platform 100 for members of the organization. The profiles service 114 can also include profile information for members of the organization such as usernames, authentication credentials, email addresses, team associations, organizational roles; as taught by DASDAN),
the method comprising: causing generation of a graphical user interface of a content collaboration platform (see figs. 3A-3C, par. 0060, wherein FIG. 3A shows an example user interface 300 for a collaboration system, such as the collaboration system 100 described herein. The user interface 300 can include one or more regions or panes that are used to display graphical objects and other information to a user and can include various interface elements that can be selected by a user to perform different functions. For example, the user interface 300 can include a navigation pane 302 that displays graphical objects that are associated with documents hosted by the collaboration system. The user interface 300 can also include a content pane 304 that includes content associated with a particular document, content page, or other content, all of which are referred to herein generically as a document; as taught by DASDAN),
the graphical user interface including an editor panel configured to receive user-generated content for an electronic document (see figs 3A-3D, par. 0064, wherein FIG. 3C shows an example of an automation editor 320 that can be used to generate an automation rule for documents hosted by the collaboration system. The automation editor 320 can be launched in response to determining a change to the hierarchical structure of one or more graphical objects as described herein. This can include changing the nodal structure that is used to organize the graphical objects in the user interface, archiving documents, removing documents, displaying documents in different sub-spaces and so on; as taught by DASDAN)
and a navigation panel displaying a hierarchical element tree having a set of elements selectable to cause display of a respective electronic document (see figs. 3A-3D, par. 0061, wherein the navigation pane 302 can be organized in a variety of ways. In some cases, as illustrated in FIG. 3A, the navigation pane 302 can have a nodal hierarchical structure that displays references to documents according to their dependent relationships. For example, a first level hierarchical structure can include a space 310, which may be a collection of documents that have a common criteria; as taught by DASDAN);
in response to a first user input to the graphical user interface, the first user input configured to initiate an action associated with an action type (see par. 0020, wherein in some cases, an automation can be created and suggested based on a type of content item the user is creating, a group or team associated with content item(s) and so on. In other cases, an automation can be created and/or suggested based on a type of action a user is performing. This can include tracking and analyzing a user's previous interactions with the service, or program to identify high frequency tasks, or other tasks routinely performed by a user. For example, a series or user event logs or other user interaction records may be analyzed in order to determine a proposed automation rule that is to presented to the user; as taught by DASDAN);
select an automation rule template corresponding to the action type (see par. 0042, wherein the recommendation engine 120 can analyze user interactions with the collaboration system, analyze history data such as stored at data platform, or analyze other data to derive automations for recommending to users of the system. The recommendation engine 120 can used event logs, user profiles and/or associated data, contextual data, and/or the like for generating information. For example, the recommendation engine 120 can track how users interact with the system and analyze this data to generate automation rules that can be proposed to users of the system. In some cases, the recommendations may be in the form of a document, such as a template for presenting content at the collaboration system 100; as taught by DASDAN),
the automation rule template configured to generate an automation rule that automatically initiates future actions associated with the action type (see par. 0098, wherein in some cases, the automation rule can be derived from the action that was performed by the user. For example, in the case of a user forwarding a particular type of content to a group of users, the automation rule can be generated to perform this task automatically; see also par. 0041, wherein the automation engine 118 can implement rules in a variety of ways including scheduling rules to execute on documents and/or other content items at defined intervals, under conditions associated with a particular rule; as taught by DASDAN);
cause display of a rule suggestion interface, the rule suggestion interface having a set of graphical elements, each respective graphical element of the set of graphical elements corresponding to a respective automation component of the automation rule template (see fig. 5, par. 0077, wherein the automation editor 506 can be launched in response to a user selecting an option to modify an automation such as described herein. In other cases, the automation editor 506 can be automatically included as part of the rule being proposed to a user. The automation editor 506 can include an editable interface 508 that has fields 510 that can be modified by a user. The fields 510 can include parameters that affect the application of the proposed automation rule. For example, the fields 510 can include an editable parameter for modifying a condition for applying the rule to a document; as taught by DASDAN);
wherein a particular graphical element of the set of graphical elements is associated with a particular automation component and is configured to receive a user-specified value (see par. 0056, wherein the automation rule includes editable fields that are pre-populated with values that are determined by the collaboration system (e.g., automation engine 118 and/or recommendation engine 120), but allows these fields to be modified by the user. For example, in the context of changing a hierarchical format for a group of documents, the automation rule may suggest that all documents currently having a first hierarchical level be updated to a new hierarchical level (e.g., from branch level 2 to branch level 3). In this regard, the user hierarchical levels may be modifiable such that a user can modify the rule; as taught by DASDAN);
DASDAN does not expressly teach and in response to a second user input requesting creation of a proposed new automation rule according to the automation rule template: determine whether the proposed new automation rule satisfies a validation criteria with respect to the particular automation component; in accordance with a determination that the proposed new automation rule fails to satisfy the validation criteria with respect to the particular automation component, provide a graphical error indication in the rule suggestion interface in association with the particular graphical element; and in accordance with a determination that the proposed new automation rule satisfies the validation criteria with respect to the particular automation component, causing creation of the proposed new automation rule.
In similar field of endeavor, PONNAN teaches and in response to a second user input requesting creation of a proposed new automation rule according to the automation rule template: determine whether the proposed new automation rule satisfies a validation criteria with respect to the particular automation component (see figs. 2A-3, par. 0043, wherein the validation module 227 validates each of the user actions recorded for the execution of the process in the generated visual representation based on at least one of user defined rules and pre-defined validation rules. In an embodiment, the visual representation is provided to the user, where the user validates each of the recorded user actions. In an embodiment, the user may define properties for each of the individual controls like text box, drop down values etc. The properties may include the list of allowed values, restrictions on length, calculation logic, conditional validations etc. The list of validation comprises validating length of the process, numeric validations for instance greater than, less than, equal to and not equal to etc., list of the allowed values, conditional validations based on the fields and data and validation of simple mathematical logic or calculations based on the available data or values; as taught by PONNAN);
in accordance with a determination that the proposed new automation rule fails to satisfy the validation criteria with respect to the particular automation component, provide a graphical error indication in the rule suggestion interface in association with the particular graphical element (see par. 0046, wherein the execution environment check comprises validation of the system resolution with that used in the automation capture, ensuring if all the applications and uniform resource locators are accessible, verification of the screen size, validation of the entire set of control ids, control types to determine any change in the application etc. In addition, the automation execution module 233 maintains detailed logs of all the events, timestamps and errors if any and all system generated messages; as taught by PONNAN);
and in accordance with a determination that the proposed new automation rule satisfies the validation criteria with respect to the particular automation component, causing creation of the proposed new automation rule (see par. 0045, wherein the execution sequence creation module 231 creates the execution sequence of the process based on the generated visual representation of the process and the one or more automation rules. In an embodiment, the execution sequence creation module 231 comprises at least one of addition and modification of the execution sequence. In an embodiment, the pre-processing of the user actions is performed before the actual automation of the process. The pre-processing of the process is performed to ensure that there is no impact on the actual user data; as taught by PONNAN).
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 DASDAN apparatus to include the teachings of PONNAN wherein and in response to a second user input requesting creation of a proposed new automation rule according to the automation rule template: determine whether the proposed new automation rule satisfies a validation criteria with respect to the particular automation component; in accordance with a determination that the proposed new automation rule fails to satisfy the validation criteria with respect to the particular automation component, provide a graphical error indication in the rule suggestion interface in association with the particular graphical element; and in accordance with a determination that the proposed new automation rule satisfies the validation criteria with respect to the particular automation component, causing creation of the proposed new automation rule. Such a person would have been motivated to make this combination as it is advantageous for the user to be able to verify if the user input complies with the rules, and be notified of the error before the creation and execution of the automation workflow to minimize time and effort that goes into an erroneous entry (see also PONNAN, pars.0003-0004 and 0046).
As to claim 12, DASDAN and PONNAN teach the limitations of claim 8. DASDAN further teaches wherein the automation rule template includes: a trigger automation component corresponding to triggering condition; and an action automation component corresponding to the action type (see fig. 3C, par. 0065, wherein the automation editor 320 can include a rule explanation field 322, a first user interface element 324 for accepting the rule (e.g., accept button), a second user interface element 326 for modifying the rule (e.g., Modify button) and a third user interface element 328 for declining the rule (e.g., decline button). In some embodiments the rule explanation field 322 can include a natural language explanation of the rule, which can include the conditions that trigger application of the rule and the actions that occur as a result. Additionally or alternatively, the rule explanation field 322 can include pseudocode which can include Boolean operators, logical operators, arithmetic operators, and/or the like; as taught by DASDAN).
As to claim 13, DASDAN and PONNAN teach the limitations of claim 8. DASDAN further teaches wherein: the rule suggestion interface includes a text input field configured to receive a text input; and the text input is associated with the proposed new automation rule (see fig. 3C, par. 0065, wherein the automation editor 320 can include a rule explanation field 322, a first user interface element 324 for accepting the rule (e.g., accept button), a second user interface element 326 for modifying the rule (e.g., Modify button) and a third user interface element 328 for declining the rule (e.g., decline button). In some embodiments the rule explanation field 322 can include a natural language explanation of the rule, which can include the conditions that trigger application of the rule and the actions that occur as a result. Additionally or alternatively, the rule explanation field 322 can include pseudocode which can include Boolean operators, logical operators, arithmetic operators, and/or the like; as taught by DASDAN).
Claims 9 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over DASDAN et al. (US20230101588A1) in view of PONNAN et al. (US20180004545A1) and further in view of ABADI et al. (US20250348360A1).
As to claim 9, DASDAN and PONNAN teach the limitations of claim 8. DASDAN and PONNAN do not expressly teach wherein the proposed new automation rule fails to satisfy the validation criteria with respect to the particular automation component if no user-specified value has been received.
In similar field of endeavor, ABADI teaches wherein the proposed new automation rule fails to satisfy the validation criteria with respect to the particular automation component if no user-specified value has been received (see fig. 4-5C, par. 0082, wherein upon receiving the validated content from task manager 430, application 420 updates the status of the task in user interface 425 to “needs input” which alerts the user to the fact that there is new content awaiting the user's review and approval. When user interface 425 receives the user's approval of the new content, application 420 updates the status of the task to “completed” in user interface 425; as taught by ABADI).
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 DASDAN and PONNAN apparatus to include the teachings of ABADI wherein the proposed new automation rule fails to satisfy the validation criteria with respect to the particular automation component if no user-specified value has been received. Such a person would have been motivated to make this combination as it is advantageous for the user to be notified when an input is needed and it is not received to avoid confusion or failure later in the process.
As to claim 14, DASDAN and PONNAN teach the limitations of claim 13. DASDAN and PONNAN do not expressly teach wherein the text input is a title of the proposed new automation rule.
In similar field of endeavor, ABADI teaches wherein the text input is a title of the proposed new automation rule (see fig. 5A-5C, par. 0061, wherein he plan 520 is a set of actions, in a pseudocode form. Each action need not form a full sentence, and the pseudocode representation allows for logical constructs (e.g. loops, if/else or switch conditions). Actions that form part of one of the logical constructs are indented; see also par. 0063, wherein action itself (i.e. the text defining the statement) is referred to herein as the title of the action. Alternatively, the title is a brief textual summary of the action; as taught by ABADI).
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 DASDAN and PONNAN apparatus to include the teachings of ABADI wherein the text input is a title of the proposed new automation rule. Such a person would have been motivated to make this combination as it is advantageous for the user to be able to choose a title that is familiar and makes sense for the user .
Claims 10-11 are rejected under 35 U.S.C. 103 as being unpatentable over DASDAN et al. (US20230101588A1) in view of PONNAN et al. (US20180004545A1) and further in view of ROVITO et al. (US20180004545A1).
As to claim 10, DASDAN and PONNAN teach the limitations of claim 8. DASDAN and PONNAN do not expressly teach the particular graphical element includes a list of candidate values; and the computer-implemented method further includes: receiving a third user input corresponding to a user selection of a value from the list of candidate values; and generating the proposed new automation rule, wherein the proposed new automation rule includes the user selected value.
In similar field of endeavor, ROVITO teaches the particular graphical element includes a list of candidate values; and the computer-implemented method further includes: receiving a third user input corresponding to a user selection of a value from the list of candidate values; and generating the proposed new automation rule, wherein the proposed new automation rule includes the user selected value (see par. 0074, wherein FIGS. 4-11 illustrate example user interfaces generated by the automation environment 20 shown in FIG. 1. The user interfaces are not exhaustive but illustrate a number of different examples. FIG. 4 illustrates an example user interface for managing rental units (also “units”). In this embodiment, the interface access engine 23 has determined that a user account with the role of property manager should be provided a list of units. This list would not, for example, be provided to a user account with the role of resident. The property manager is thus able to see a list of units, the vacancy status of those units, assigned staff members, and the automation settings of one or more automation devices at each unit (among potentially other information); as taught by ROVITO).
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 DASDAN apparatus to include the teachings of ROVITO wherein the particular graphical element includes a list of candidate values; and the computer-implemented method further includes: receiving a third user input corresponding to a user selection of a value from the list of candidate values; and generating the proposed new automation rule, wherein the proposed new automation rule includes the user selected value. Such a person would have been motivated to make this combination as it is advantageous for the user to be presented with a list of values to select from than just inputting a value without any context or example at hand (see ROVITO, fig. 1, par. 0024).
As to claim 11, DASDAN, PONNAN and ROVITO teach the limitations of claim 10. DASDAN further teaches in response to selecting the automation rule template, sending a request to a third-party service to request the list of candidate values (see par. 0121, wherein the various functions and operations of a system such as described herein can be implemented in a number of suitable ways, developed for leveraging any number of suitable libraries, frameworks, first or third-party APIs, local or remote databases; as taught by DASDAN).
ROVITO further teaches and receiving, from the third-party service, the list of candidate values for display in the rule suggestion interface (see par. 0074, wherein the interface access engine 23 has determined that a user account with the role of property manager should be provided a list of units. This list would not, for example, be provided to a user account with the role of resident. The property manager is thus able to see a list of units, the vacancy status of those units, assigned staff members, and the automation settings of one or more automation devices at each unit (among potentially other information); as taught by ROVITO).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Publication Number
Filing Date
Title
US20250356313A1
2024-05-20
Multi-agent task management guided by generative artificial intelligence
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KOOROSH NEHCHIRI whose telephone number is (408)918-7643. The examiner can normally be reached M-F, 11-7 PST.
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, William L. Bashore can be reached on 571-272-4088. 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.
/KOOROSH NEHCHIRI/Examiner, Art Unit 2174
/WILLIAM L BASHORE/ Supervisory Patent Examiner, Art Unit 2174
Prosecution Insights