DETAILED ACTION
Response to Amendment
This Non-Final office action is in response to Applicant’s amendment filed 9/8/2025. 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 9/8/2025 have been fully considered but they are not persuasive. Additionally, this Non-Final rejection is based on the application of the cited prior art over the claim language.
Regarding the previously pending 35 USC 101 rejection to method claims 11-20, the claims as a whole, recite additional elements that integrate the judicial exception into a practical application, under Prong Two of Step 2A of the Alice analysis.
Specifically, independent claim 11 recites “managing, by the computer system, environment state information maintaining a collaboration environment, and automation information…the automation information specifying a first trigger-action pair, the first trigger-action pair including 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: establishing, by the computer system, a connection with the payment application resource that is managed outside of the collaboration environment; and causing, by the computer system, the payment application resource to perform the first automated action outside the collaboration environment, the first automated action including sending one or more electronic payments.”
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).
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: 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 one or more electronic payments.
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: 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 one or more electronic payments 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 the rejection of claim 1 should be withdrawn at least because claim 1, which is amended herein without acknowledging propriety of the current rejection and solely to expedite prosecution, recites features related to an automation comprising a trigger-action pair, where an external payment execution action is triggered an occurrence within a collaboration environment. None of the cited references, alone or in combination, teach or suggest these features.
The manner in which the Office Action alleges Pearl both discloses "a first automated action to carry out by a payment application resource outside of the collaboration environment" and concurrently does not disclose "cause the payment application resource to perform the first automated action" is logically inconsistent. This is a fundamental deficiency in the enunciation of the rejection and is a basis upon which the rejection should be withdrawn.
Moreover, the Office Action's approach to combining Pearl and Rathod cannot support a rejection of at least the amended claims because it reflects an improper dissection of the "trigger-action pair" feature of the amended claims. It is well established that Office personnel "may not dissect a claimed invention into discrete elements and then evaluate the elements in isolation." [MPEP 2103 I C]. Relying on an "action" in Rathod and a "trigger" in Pearl would reflect an improper dissection because the amended claim feature is a "trigger-action pair." Even if, for argument's sake and without concession, Rathod's operation of "make payments" could be inferred as being part of a trigger-action pair, to allege that a combination with Pearl causes Pearl's trigger to become the trigger to Rathod's trigger- action pair would require a substantial functional change to the trigger-action pair of Rathod. The trigger-action pairs of the references are performing a different function separately than when combined as proposed. This supports a conclusion that such a combination would not be obvious under at least finding (2) of the rationale "Combining Prior Art Elements According to Known Methods To Yield Predictable Results." [MPEP 2143 I A]. The Examiner respectfully disagrees.
As discussed in the updated rejection and contrary to Applicant’s assertion, Pearl et al disclose indeed disclose Applicant’s amended claim language. Specifically, Pearl et al disclose 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.
Additionally, and contrary to Applicant’s assertion, the Office Action's approach to combining Pearl and Rathod indeed supports a rejection the amended claims. Here, there has been no dissection or evaluation of the elements in isolation. Rather, the claims as a whole have been be considered.
Here, Pearl et al disclose 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 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). For example, 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).
Additionally, 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).
As a result, and contrary to Applicant’s assertion it is clear that Pearl et al describes an event-based automation engine to automatically trigger polices and/or automations, while Rathod describes triggering an action including making payments.
As a result, and contrary to Applicant’s bald assertion, there would be no substantial functional change to Rathod and the references are not performing a different function separately than when combined as proposed.
Following, the key to supporting any rejection under 35 U.S.C. 103 is the clear articulation of the reason(s) why the claimed invention would have been obvious. The Supreme Court in KSR noted that the analysis supporting a rejection under 35 U.S.C. 103 should be made explicit. The Court quoting In re Kahn, 441 F.3d 977, 988, 78 USPQ2d 1329, 1336 (Fed. Cir. 2006), stated that "‘[R]ejections on obviousness cannot be sustained by mere conclusory statements; instead, there must be some articulated reasoning with some rational underpinning to support the legal conclusion of obviousness.’" KSR, 550 U.S. at 418, 82 USPQ2d at 1396. Exemplary rationales that may support a conclusion of obviousness include: (A) Combining prior art elements according to known methods to yield predictable results, as used here. See MPEP §2141.
The rationale to support a conclusion that the claim would have been obvious is that all the claimed elements were known in the prior art and one skilled in the art could have combined the elements as claimed by known methods with no change in their respective functions, and the combination yielded nothing more than predictable results to one of ordinary skill in the art. KSR, 550 U.S. at 416, 82 USPQ2d at 1395; Sakraida v. AG Pro, Inc., 425 U.S. 273, 282, 189 USPQ 449, 453 (1976); Anderson’s-Black Rock, Inc. v. Pavement Salvage Co., 396 U.S. 57, 62-63, 163 USPQ 673, 675 (1969); Great Atl. & P. Tea Co. v. Supermarket Equip. Corp., 340 U.S. 147, 152, 87 USPQ 303, 306 (1950). "[I]t can be important to identify a reason that would have prompted a person of ordinary skill in the relevant field to combine the elements in the way the claimed new invention does." KSR, 550 U.S. at 418, 82 USPQ2d at 1396. See MPEP §2143.
In addition, as discussed in the KSR International Co. v. Teleflex Inc. et al., 550 U.S. ____(2007), “[o]ften, it will be necessary for a court to look to interrelated teachings of multiple patents; the effects of demands known to the design community or present in the marketplace; and the background knowledge possessed by a person having ordinary skill in the art, all in order to determine whether there was an apparent reason to combine the known elements in the fashion claimed by the patent at issue. To facilitate review, this analysis should be made explicit. See In re Kahn, 441 F. 3d 977, 988 (CA Fed. 2006) (‘[R]ejections on obviousness grounds cannot be sustained by mere conclusory statements; instead, there must be some articulated reasoning with some rational underpinning to support the legal conclusion of obviousness’). As our precedents make clear, however, the analysis need not seek out precise teachings directed to the specific subject matter of the challenged claim, for a court can take account of the inferences and creative steps that a person of ordinary skill in the art would employ” (emphasis added).
Conclusion
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 December 13, 2025