DETAILED ACTION
Response to Amendment
This Final office action is in response to Applicant’s amendment filed 4/17/2026. Claims 1 and 11 have been amended. Claims 1-20 are pending.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Applicant's arguments filed 4/17/2026 have been fully considered but they are not persuasive.
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 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.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Pearl et al (US 20170346861 A1), in view of Rathod (US 20110225293 A1).
As per claim 1, Pearl et al disclose a system configured to effectuate automated actions outside a collaboration environment based on trigger events occurring within the collaboration environment, the system comprising:
one or more physical processors configured by machine-readable instructions (i.e., Signals received or detected indicating user activity at client devices 102 through one or more of the above input mechanism, or others, can be used in the disclosed technology by various users or collaborators (e.g., collaborators 108) for accessing, through network 106, a web-based collaboration environment or online collaboration platform (e.g., hosted by the host server 100), ¶ 0038) to:
manage environment state information maintaining a collaboration environment, and automation information characterizing user-defined automations including trigger-action pairs (i.e., metadata rules can be defined based on keys of key value pairs. In some embodiments, threshold or defined values for the metadata key-value pairs can be set that trigger the rule. For example, if the metadata template defines a contract, then one metadata attribute may be the value of the contract. A rule can be set that triggered a particular action or job in the event that the value of the contract exceeds a particular preset value. For instance, one or more notifications may be sent to particular individuals for review. Similarly, a metadata attribute of a contract template could include a status attribute that causes a particular action or job to be performed when the value of the key-value pair change from ‘PENDING’ to ‘APPROVED’. In this manner, metadata or changes to metadata can trigger job requests (e.g., events or actions), ¶ 0085), the collaboration environment being configured to facilitate interaction by users with the collaboration environment (i.e., The collaboration platform or environment hosts workspaces with work items that one or more users can access (e.g., view, edit, update, revise, comment, download, preview, tag, or otherwise manipulate, etc.), ¶ 0039),
the environment state information including work unit records, the work unit records including work information describing units of work created and assigned within the collaboration environment (i.e., the collaboration platform allows multiple users or collaborators to access or collaborate efforts on work items such that each user can see, remotely, edits, revisions, comments, or annotations being made to specific work items through their own user devices, ¶ 0041),
the units of work being described based on one or more actions that the users assigned to the units of work are expected to accomplish in order to mark the units of work as complete (i.e., Similarly, in the same user interface where discussion topics can be created in a work space (e.g., work space A, B or N, etc.), actionable events on work items can be created and/or delegated/assigned to other users such as collaborators of a given work space 206 or other users. Through the same user interface, task status and updates from multiple users or collaborators can be indicated and reflected. In some instances, the users can perform the tasks (e.g., review or approve or reject, etc.) via the same user interface, ¶ 0057, wherein The status engine 825 can track and/or otherwise monitor the status of jobs submitted to the queues. The status engine 825 ensures that jobs are executed. In one embodiment, jobs and status updates (started, completed, failed) are persisted in a local database (e.g., the local HBase cluster), ¶ 0105),
the automation information specifying a first trigger-action pair, the first trigger-action pair including a first automated action by a resource outside of the collaboration environment in response to a first trigger event occurring within the collaboration environment (i.e., Similarly, a metadata attribute of a contract template could include a status attribute that causes a particular action or job to be performed when the value of the key-value pair change from ‘PENDING’ to ‘APPROVED’. In this manner, metadata or changes to metadata can trigger job requests (e.g., events or actions), ¶ 0085, wherein In one embodiment, the architecture integrates a metadata service with an event-based automation engine to automatically trigger polices and/or automations based on metadata and/or metadata changes. For example, when a user uploads a file and classifies it using metadata as highly confidential, this can trigger a particular policy or automation, ¶ 0026, The administrator interface 705 can include a network interface having a networking module that enables the rule manager 700 to mediate data in a network with an entity that is external to the rule manager 700, through any known and/or convenient communications protocol supported by the host and the external entity, ¶ 0083), and
responsive to detection of occurrence of the first trigger event (i.e., The job request generation engine 740 is also configured to process key-value pairs associated with the metadata events to conditionally generate job requests (e.g., if the rule is triggered), ¶ 0093): determine whether a result of the first automated action is already fulfilled, responsive to a determination that the result of the first automated action is fulfilled, do not execute the first automated action (i.e., The leader election engine 815 can be used to guarantee that only one instance of the job manager 800 is performing operations so that the operations are not duplicated. For example, in one embodiment, the leader election engine 815 is utilized to ensure that only one service in each cluster is retrying and/or replicating jobs, ¶ 0098).
Pearl et al does not disclose a first automated action to carry out by a payment application resource outside of the collaboration environment in response to a first trigger event occurring within the collaboration environment; and responsive to detection of occurrence of the first trigger event: responsive to a determination that the result of the first automated action is not fulfilled establish a connection with the payment application resource that is managed outside of the collaboration environment; and cause the payment application resource to perform the first automated action outside the collaboration environment, the first automated action including sending of the electronic payment.
Rathod discloses collaboration and discovery are important aspects of knowledge management in a P2P environment one such example of it is a Groove Networks developed by Ray Ozzie which offers a Groove platform for development and deployment of collaborative solutions based on peer to peer communications. A platform consists of the Groove client, underpinned by system, development and integration services, enabling group of users to communicate and share information using a set of out of the box tools including instant messaging, live voice, text chat, and file sharing, viewing and editing (¶ 0019).
FIGS. 26 through 31 illustrating wizard interfaces for each of channel node with respect to specific accomplishment via other channel nodes. FIGS. 26 to 31 illustrating example of graphical user interface (GUI) for Service Provider (HSNSP), HSNHA, HSNS, and HSND active wizards illustrating each of GUI for each of channel node and HSN controller along with the formatting parameters thereof, the formatting parameter selection is based on the predetermined selection logic for each of channel node wherein each of steps providing multiple options to choose from so as to accomplish the selected task (¶ 0334).
The general tasks accomplishment by each of provider via wizard in FIG. 26 with respect to particular channel node to be accomplished are as follows: for Developer (26A): a. download AI agents, utilities, and application, b. make payments, c. get product details, d. register; for HSN controller (26B): a. check service details, b. make payments (¶ 0335).
Rathod discloses users are being enabled to bookmark, save results or sent queries to selected sources and can click hyperlink for more details, further performing 3rd click operations on hyperlinks for more actions like ask for more details, subscribe and make payments, sort results (node wise, ASC, DESC etc.), take printouts etc., (¶ 0329). User service(s) availabilities are based on so many factors including automatically determining availabilities of service(s) based on number of minutes user PC is not accessed, user timings and duration, user location, particular days, triggering of user's one or more defined activities, actions, events and transactions (¶ 0433).
Pearl et al and Rathod are concerned with effective environment collaboration. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include a first automated action to carry out by a payment application resource outside of the collaboration environment in response to a first trigger event occurring within the collaboration environment; and responsive to detection of occurrence of the first trigger event: responsive to a determination that the result of the first automated action is not fulfilled establish a connection with the payment application resource that is managed outside of the collaboration environment; and cause the payment application resource to perform the first automated action outside the collaboration environment, the first automated action including sending of the electronic payment in Pearl et al, as seen in Rathod, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
As per claim 2, Pearl et al disclose the first automated action is defined by a target component and an action component, the target component identifying the payment application resource outside the collaboration environment to which an action is to be carried out with, and the action component defining instructions to effectuate the action by the payment application resource outside the collaboration environment (i.e., the host server can generate notifications or notification events for one or more of the plurality of activities and select one or more recipients for each notification. Various mechanisms or external messaging applications can then be used to notify users or collaborators, including through the web interface to access the collaboration platform, via email, and/or SMS, for example, ¶ 0047).
As per claim 3, Pearl et al disclose the instructions to effectuate the action by the payment application resource outside the collaboration environment includes performing an application programming interface call to the payment application resource to cause the payment application resource to execute a routine in accordance with the action (i.e., As shown in the example of FIG. 6, the rules-based engine includes an action log 605, an administrator interface 610, a rule manger 620, and a rule database 625. The computing platform includes a direction application program interface (API) 630, a jobs manager 620, multiple storage databases 645 and 646, and multiple workers 650A-N, ¶ 0077).
As per claim 4, Pearl et al disclose the one or more physical processors are further configured by the machine-readable instructions to: generate the automation information based on user entry or selection of the automation information into a user interface i.e., As described herein, the event-based automation engine includes a rule-based engine to automatically translate each event into one or more jobs based on user-specified rules (e.g., administrator-specified rules) and the job manager, ¶ 0049. In a user interface of the web-based collaboration platform where notifications are presented, users can, via the user interface, create action items (e.g., tasks) and delegate the action items to other users including collaborators pertaining to a work item 215, ¶ 0057).
As per claim 5, Pearl et al disclose the first trigger event is associated with individual occurrences of change to first work information of a first work unit record of a first unit of work, and wherein the one or more physical processors are further configured by the machine-readable instructions to: detect the occurrence of the first trigger event based on occurrence of the change to the first work information (i.e., In one embodiment, the architecture integrates a metadata service with an event-based automation engine to automatically trigger polices and/or automations based on metadata and/or metadata changes. For example, when a user uploads a file and classifies it using metadata as highly confidential, this can trigger a particular policy or automation, ¶ 0026, wherein A rule can be set that triggered a particular action or job in the event that the value of the contract exceeds a particular preset value. For instance, one or more notifications may be sent to particular individuals for review. Similarly, a metadata attribute of a contract template could include a status attribute that causes a particular action or job to be performed when the value of the key-value pair change from ‘PENDING’ to ‘APPROVED’, ¶ 0085).
As per claim 6, Pearl et al disclose the first trigger event is associated with a specific change to first work information of a first work unit record of a first unit of work, and wherein the one or more physical processors are further configured by the machine-readable instructions to: detect the occurrence of the first trigger event based on occurrence of the specific change to the first work information (i.e., threshold or defined values for the metadata key-value pairs can be set that trigger the rule. For example, if the metadata template defines a contract, then one metadata attribute may be the value of the contract. A rule can be set that triggered a particular action or job in the event that the value of the contract exceeds a particular preset value, ¶ 0085).
As per claim 7, Pearl et al disclose the first automated action is carried out immediately or within a specified time frame following the detection of the occurrence of the first trigger event (i.e., when an action is performed on a work item by a given user or any other activity is detected in the work space, other users in the same work space may be notified (e.g., in real time or in near real time, or not in real time). Activities which trigger real time notifications, ¶ 0055).
As per claim 8, Pearl et al disclose further comprising non-transitory electronic storage storing one or more automation templates, an automation template specifying a predetermined set of automated actions to carry out outside the collaboration environment in response to occurrence of a predetermined trigger event occurring within the collaboration environment (i.e., an administrator system 410 can be configured to bypass the front-end systems in order to directly submit a job, determine the status of a job, kill a job, etc. via a web interface or application program interface built into the event-based automation engine 430. In some embodiments, clients, users and/or administrators can access the metadata service engine 450 in order to select, configure, and/or generate templates or provide input for metadata searching, ¶ 0066).
As per claim 10, Pearl et al disclose the first trigger event is a completion state change to a first unit of work described by a first work unit record A rule can be set that triggered a particular action or job in the event that the value of the contract exceeds a particular preset value. For instance, one or more notifications may be sent to particular individuals for review. Similarly, a metadata attribute of a contract template could include a status attribute that causes a particular action or job to be performed when the value of the key-value pair change from ‘PENDING’ to ‘APPROVED’, ¶ 0085, and wherein the one or more physical processors are further configured by the machine-readable instructions to: detect the occurrence of the first trigger event based on occurrence of the completion state change (i.e., jobs and status updates (started, completed, failed) are persisted in a local database, ¶ 0105).
Claims 11-18 and 20 are rejected based upon the same rationale as the rejection of claims 1-8 and 10, respectively, since they are the method claims corresponding to the system claims.
Claims 9 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Pearl et al (US 20170346861 A1), in view of Rathod (US 20110225293 A1), in further view of Tsypliaev et al (US 9565246 B1).
As per claim 9, Pearl et al does not disclose the first trigger event is a due date change to a first unit of work described by a first work unit record, and wherein the one or more physical processors are further configured by the machine-readable instructions to: detect the occurrence of the first trigger event based on occurrence of the due date change.
Tsypliaev et al disclose it is not necessary to fill in misleading percentages of task completion or unrealistic due dates. Comindware Project can determine achievable deadlines by tracking the real task progress, based on estimated time minus logged time. Baselines can be used to make snapshots of the project plan as it was at a particular date. This way, it is possibly to view how the project plan is changing in time and make appropriate corrections. Task Deadline Alerts can be used to be instantly updated if tasks are behind their schedule and thus need the attention (column 25, lines 55-65).
Pearl et al and Tsypliaev et al are concerned with effective workforce management. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the first change is a due date change in Pearl et al, as seen in Tsypliaev et al, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Claim 19 is rejected based upon the same rationale as the rejection of claim 9, since it is the method claim corresponding to the system claim.
Response to Arguments
In the Remarks, Applicant argues amended claim 1 recites features related to an automation routine including a pre-execution fulfillment audit of a result before establishing a connection to a payment application to execute a transaction. None of the cited references, alone or in combination, teach or suggest a system that possesses state-awareness to determine if a desired result-such as an electronic payment being sent-has already been fulfilled in an external environment to prevent redundant or erroneous automated actions.
Pearl does not describe the amended claim features because its logic is strictly one-way and/or event-driven. For example, Pearl's system reacts to the occurrence of a trigger and initiates a job (such as a notification or file conversion). [Pearl, 29 ("When a rule... is met... the job engine executes one or more jobs associated with the rule")]. Pearl is silent to a pre-execution gate that audits a "result" of an action. Pearl does not "determine whether a result... is already fulfilled" before acting; rather, it executes the rule as soon as the metadata state changes. The Examiner respectfully disagrees.
As discussed in the updated rejection, Pearl et al indeed disclose Applicant’s amended claim language. Specifically, Pearl et al disclose the leader election engine 815 can be used to guarantee that only one instance of the job manager 800 is performing operations so that the operations are not duplicated. For example, in one embodiment, the leader election engine 815 is utilized to ensure that only one service in each cluster is retrying and/or replicating jobs, ¶ 0098.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANDRE D BOYCE whose telephone number is (571)272-6726. The examiner can normally be reached M-F 10a-6:30p.
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, Rutao (Rob) Wu can be reached at (571) 272-6045. 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.
/ANDRE D BOYCE/Primary Examiner, Art Unit 3623 July 22, 2026
Prosecution Insights