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 .
With regards to the prior 35 USC 112 rejections, they are withdrawn in view of comments/remarks in applicant’s response on 12/22/2025.
The following rejections are withdrawn in view of applicant’s amendments:
Claim(s) 1 – 8, 10, 12 – 14, and 18-22 rejected under 35 U.S.C. 103 as being unpatentable over Gazze et al (“WorkMail: Collaborative Document Workflow Management by Email”, publisher: Springer-Verlag Berlin Heidelberg, published: 2012, pages 14-23) in view of Tonnison et al (US Application: US 2008/0046518, published: Feb. 21, 2008, filed: Aug. 16, 2006) in view of Dunkley (US Application: US 20060288222, published: Dec. 21, 2006, filed: Jun. 1, 2006) in view of Bacastow et al (US Application: US 2005/0228836, published: Oct. 13, 2005, filed: Apr. 8, 2005).
Claim(s) 9 rejected under 35 U.S.C. 103 as being unpatentable over Gazze et al (“WorkMail: Collaborative Document Workflow Management by Email”, publisher: Springer-Verlag Berlin Heidelberg, published: 2012, pages 14-23) in view of Tonnison et al (US Application: US 2008/0046518, published: Feb. 21, 2008, filed: Aug. 16, 2006) in view of Dunkley (US Application: US 20060288222, published: Dec. 21, 2006, filed: Jun. 1, 2006) in view of Bacastow et al (US Application: US 2005/0228836, published: Oct. 13, 2005, filed: Apr. 8, 2005) and in view of Argent (US Application: US 2013/0283145, published: Oct. 24, 2013, filed: Apr. 10, 2013)
Claim(s) 11 rejected under 35 U.S.C. 103 as being unpatentable over Gazze et al (“WorkMail: Collaborative Document Workflow Management by Email”, publisher: Springer-Verlag Berlin Heidelberg, published: 2012, pages 14-23) ) in view of Tonnison et al (US Application: US 2008/0046518, published: Feb. 21, 2008, filed: Aug. 16, 2006) in view of Dunkley (US Application: US 20060288222, published: Dec. 21, 2006, filed: Jun. 1, 2006) in view of Bacastow et al (US Application: US 2005/0228836, published: Oct. 13, 2005, filed: Apr. 8, 2005) in view of Chumakova (“How to Transform your Outlook into a Workflow System”, published: January 2015, pages 1-4)
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 12/08/2025, 03/03/2026 and 04/28/2026 are being considered by the examiner.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1 – 5, 7, 8, 10, 13 – 14, and 18-22 are rejected under 35 U.S.C. 103 as being unpatentable over Gazze et al (“WorkMail: Collaborative Document Workflow Management by Email”, publisher: Springer-Verlag Berlin Heidelberg, published: 2012, pages 14-23) in view of Anjum et al (US Application: US 2022/0138161, filed: Oct. 30, 2020 (Anjum et al was cited from applicant’s submitted IDS filed on 12/08/2025) in view of Dunkley (US Application: US 20060288222, published: Dec. 21, 2006, filed: Jun. 1, 2006) in view of Bacastow et al (US Application: US 2005/0228836, published: Oct. 13, 2005, filed: Apr. 8, 2005).
With regards to claim 1, Gazzè et al teaches a method of information processing, comprising:
establishing an association relationship between a first application (page 17: “WorkMail is a web-based application”) and a first file (a first file is a workmail file that acts like an email file/document (obtained online via network and email server in Figure 2). As additionally explained in page 19, “we need a container to deliver the shared document between users, so another content type has been created to contain the attachment. This new content type (workmail) has as many instances as the number of users involved and performs the role of the classic email), the first application being a program for processing a service processing flow (Fig. 2 and 3: the workmail application implements the processing flow of a document which includes access control” );
obtaining service processing flow information from the first application (paged 18 and 19: “When a user creates an email with a document attached the engine creates: – workmail content types for each user in the recipient; – a single attachment content type… To make document’s editing really cooperative, different permissions to different roles can be assigned to every single field in the document configuration (interpreted as flow information). Every attachment node has not a prefixed permission setting, because in our case the flow is dynamic and not static. So the engine is capable of calculating the right permission at runtime, depending on the content of the recipient field”); and
[including] first information … in the first file (pages 19 and top of page 20: information such as the body or read flags can be displayed in an interface similar to a web-email client).
wherein the service processing flow comprises a first node and a second node subsequent to the first node, and the service processing flow proceeds to the second node in response to the first node in the service processing flow being approved (pages 19-22, section 3.2, Figure 4: a service processing flow a document is delivered to each specific stage ((node)) having a recipient in a workflow and a workflow can comprise a first node/stage such as ‘employee manager for preliminary authorization’ stage, and proceeds to a subsequent stage (node) such as ‘director for final authorization’ as a second type of node (after the recipient manager of first node completes his preliminary authorization)).
However Gazzè et al does not expressly teach generating first information corresponding to the service processing flow information at a predetermined position in the first file; displaying the first information as file content at the predetermined position in the first file; … wherein a save strategy is configured for the first file, the save strategy for the first file comprises a save duration of the first file, and configuring the save strategy comprises: displaying a file save directory corresponding to a server by the first application via a first interface predetermined in the first application, the first interface being pre-established to associate the server with the first application; and in response to a user operation on the file save directory, determining a target save address of the first file to save the first file to the server, wherein the save strategy is configured by a user at a time point before an end of the service processing flow, the save strategy is used to save the first file after the end of the service processing flow.
Yet Anjum et al teaches generating first information corresponding to the service processing flow information at a predetermined position in the first file ; displaying the first information as file content at the predetermined position in the first file; … , and the service processing flow is ended in response to all nodes in the service processing flow being approved or one of the nodes in the service processing flow being opposed (Fig 6, paragraphs 0021, 0045: processing flow information such as ‘agreed’ and ‘approved’ are each included within a position within the file /document. Additionally, different items for negotiation for different items required for workflow is considered complete when there is an agreement of clauses in a document as a whole ).
It would have been obvious to one of ordinary skill in the art before the effective filing of the invention to have modified Gazzè et al’s ability to 1) send a message-file/email (having a body and further including an attached second file) to another recipient at each stage/step of a workflow (claimed node) and 2) routed the message-file and corresponding data to a next required item in a workflow after approval has been satisfied), such that each required item (node) in a workflow for approval could be displayed within a document file and each required item could also require an agreement of all required items for finalization/completion of workflow, as taught by Anjum et al . The combination would have allowed Gazzè et al to have managed changes/versions and reduced delays/confusion in a negotiation process (Anjum et al, paragraph 0003).
However Gazzè et al and Anjum et al does not expressly teach wherein a save strategy is configured for the first file, the save strategy for the first file comprises a save duration of the first file, and configuring the save strategy comprises: displaying a file save directory corresponding to a server by the first application via a first interface predetermined in the first application, the first interface being pre-established to associate the server with the first application; and in response to a user operation on the file save directory, determining a target save address of the first file to save the first file to the server wherein the save strategy is configured by a user at a time point before an end of the service processing flow, the save strategy is used to save the first file after the end of the service processing flow.
Yet Dunkley teaches wherein a save strategy is configured for the first file …, and configuring the save strategy comprises: displaying a file save directory corresponding to a server by the first application via a first interface predetermined in the first application, the first interface being pre-established to associate the server with the first application (Fig 4, paragraphs 0022, 0023, 0035, 0069, 0071: a file save directory field in a first form designer configuration interface can be displayed for a file/document for return options in a form data return workflow application. The form designer interface for return options of the file/document/form and the interface includes an Address field (such as FTP server address Field) to pre-establish the address of the server and directory for the document/file/form processing application prior to form distribution and form data return-workflow); and in response to a user operation on the file save directory, determining a target save address of the first file to save the first file to the server wherein the save strategy is configured by a user at a time point before an end of the service processing flow, the save strategy is used to save the first file after the end of the service processing flow, and the service processing flow is ended (Fig 4, paragraphs 0021, 0039, 0052, 0060, 0070 and 0071: a user manages how the file is saved by selecting the file save directory field and entering the directory location in the field prior to the file/form distribution, and in response to the directory location the form/file is saved (at the end of the current form’s processor flow that has at least all return steps (nodes/items-required for a workflow) completed for the instant form in the flow , which include signing and selecting return to sender button).
It would have been obvious to one of ordinary skill in the art before the effective filing of the invention to have modified Gazze et al and Anjum et al ability to generate information in response to processing of a workflow/service-flow (that can require/support multiple approval recipients per node and traverse nodes upon a particular flow/stage ending based on approvals) corresponding to a first email file, such that the file would have been configured with a save strategy/location prior to distribution workflow, and the file would have been saved according to the configuration at completion/ending of a set of steps for form completion/return flow, as taught by Dunkley.. The combination would have allowed Gazze et al, and Anjum et al to have performed data collection from distributed … sources and improved costs, turnaround time, and reliability of data … by reducing the need for staff and/or consultants …” (Dunkley, paragraph 0020).
However, although the combination of Gazze et al, Anjum et al and Dunkley teaches it is known to pre establish a save strategy with parameters such as a save address to a server prior to form service flow using a form designer configuration interface, the combination does not expressly teach …, the save strategy for the first file comprises a save duration of the first file.
Yet Bacastow et al teaches …, the save strategy for the first file comprises a save duration of the first file (Figure 6, Figure 10, claim 12 of Bacastow et al: a specific file backup strategy can be part of a configuration interface for which the user can specify a duration of time between backups for the file).
It would have been obvious to one of ordinary skill in the art before the effective filing of the invention to have modified Gazze et al, Anjum et al and Dunkley’s ability to pre-establish a save strategy using a configuration interface to set parameters for a file/form, such that the configuration interface would have included an option to set the file duration of time between backups as taught by Bacastow et al. The combination would have allowed Gazze et al, Anjum et al and Dunkley to have flexibly and efficiently allowed a user to configure a backup schedule for a target file.
With regards to claim 2. The method of claim 1, Gazzè et al teaches wherein establishing an association relationship between a first application and a first file comprises: adding the first file in a processing interface of the first application; or, generating the first file based on processing flow information of the first application (the first file/workmail-content-type is associated with the workmail application as explained in page 20: “While the InBox and SentBox are similar to those of standard email clients, the Compose Tab is different. Differently from standard email clients, a section containing suggested attachments is presented. When a user chooses the type of the attachment, the system shows an instance of the document that the user can fill out. The visibility of each field of the document and his proprieties (readable, editable) depend on the user and on the step of the flow. After saving, the user can see the attachment in the compose area.”);.
With regards to claim 3. The method of claim 1, Gazzè et al teaches wherein, the first file is a file processed by the service processing flow (a first file/workmail content file acts as a container email as explained in pages 18 and 19: “When a user creates an email with a document attached the engine creates: – workmail content types for each user in the recipient; – a single attachment content type…”)..
With regards to claim 4. The method of claim 1, Gazzè et al teaches wherein, the first file carries a second file for the service processing flow (an attachment is the second file carried by the workmail content file as explained in pages 18 and 19: “When a user creates an email with a document attached the engine creates: – workmail content types for each user in the recipient; – a single attachment content type…”)).
With regards to claim 5. The method of claim 1, Gazze et al, Anjum et al, Dunkley and Bacastow et al teaches wherein, the first information comprises all or part of the service processing flow information; or, the first information is configured to display all or part of the service processing flow information after being triggered, as similarly explained in the rejection of claim 1 (Gazzè et al’s first information for an email file/document was modified by Anjum et al’s ability to display the first information in a position on a display and the first information includes workflow state/stage that could have been triggered by a sender’s send-action), and is rejected under similar rationale.
With regards to claim 7. The method of claim 1, Gazze et al, Anjum et al, Dunkley and Bacastow et al teaches wherein the service processing flow information comprises at least one of: service processing node information, service processing person information, service processing opinion information, or service processing time information, as similarly explained in the rejection of claim 1 (Anjum et al was explained to teach approval (opinion) status ), and is rejected under similar rationale.
With regards to claim 8. The method of claim 7, Gazze et al, Anjum et al, Dunkley and Bacastow et al teaches wherein, the service processing opinion information comprises processing result information of a first service processing node in the service processing flow, as similarly explained in the rejection of claim 1 (Anjum et al was explained to show workflow processing result/state of the document for earlier clauses/parts of the document), and is rejected under similar rationale.
With regards to claim 10. The method of claim 1, Gazze et al, Anjum et al, Dunkley and Bacastow et al teaches wherein the first information comprises link information and displaying first information at a predetermined position in the first file comprises: displaying the link information at the predetermined position in the first file, the link information displaying the service processing flow information of the first application after being triggered, as similarly explained in the rejection of claim 6, and is rejected under similar rationale.
With regards to claim 13. The method of claim 1, Gazze et al, Anjum et al, Dunkley and Bacastow et al teaches wherein, the first file comprises an online document, as similarly explained in the rejection of claim 1 (the email file/document was explained to have been received online via a network), and is rejected under similar rationale.
With regards to claim 14. The method of claim 1, Gazze et al, Anjum et al, Dunkley and Bacastow et al teaches wherein, the service processing flow comprises an approval flow, a reporting flow, or a project management flow; and the first file comprises a first online document for carrying a file required for approval, or reporting, or project management, as similarly explained in the rejection of claim 1 (as explained, the flow can include approval(s) from people/user(s), and other information such as report/attribute content in an email interface for the first document (email file/document) that carries a second attached file for the approval, reporting/project workflow), and is rejected under similar rationale.
With regards to claim 18. The method of information processing of claim 1, Gazze et al, Anjum et al, Dunkley and Bacastow et al teaches further comprising wherein, after the end of the service processing flow, the first file is saved based on the save strategy (as similarly explained in the rejection of claim 1, Dunkley teaches the file is saved after end of current form’s processing flow, based on save location setting), and is rejected under similar rationale).
With regards to claim 19, Gazze et al, Anjum et al, Dunkley and Bacastow et al teaches an electronic device, comprising: at least one memory and at least one processor; wherein the at least one memory is configured to store program code, and the at least one processor is configured to call the program code stored in the at least one memory to cause the electronic device to perform acts of information processing, and the acts comprises: establishing an association relationship between a first application and a first file, the first application being a program for processing a service processing flow; determining service processing flow information of the first application; and generating first information corresponding to the service processing flow information at a predetermined position in the first file, wherein a save strategy is configured for the first file, the save strategy for the first file comprises a save duration of the first file, and configuring the save strategy comprises: displaying a file save directory corresponding to a server by the first application via a first interface predetermined in the first application, the first interface being pre-established to associate the server with the first application; and in response to a user operation on the file save directory, determining a target save address of the first file to save the first file to the server, wherein the save strategy is configured by a user at a time point before an end of the service processing flow, the save strategy is used to save the first file after the end of the service processing flow, and the service processing flow is ended in response to all nodes in the service processing flow being approved or one of the nodes in the service processing flow being opposed, wherein the service processing flow comprises a first node and a second node subsequent to the first node, and the service processing flow proceeds to the second node in response to the first node in the service processing flow being approved, as similarly explained in the rejection of claim 1, and is rejected under similar rationale.
With regards to claim 20 Gazze et al, Anjum et al, Dunkley and Bacastow et al teaches a non-transitory computer storage medium, wherein, the non-transitory computer storage medium stores program code that, when executed by a computer device, causes the computer device to perform acts of information processing, and the acts comprises: establishing an association relationship between a first application and a first file, the first application being a program for processing a service processing flow; determining service processing flow information of the first application; and generating first information corresponding to the service processing flow information at a predetermined position in the first file, wherein a save strategy is configured for the first file, the save strategy for the first file comprises a save duration of the first file, and configuring the save strategy comprises: displaying a file save directory corresponding to a server by the first application via a first interface predetermined in the first application, the first interface being pre-established to associate the server with the first application; and in response to a user operation on the file save directory, determining a target save address of the first file to save the first file to the server, wherein the save strategy is configured by a user at a time point before an end of the service processing flow, the save strategy is used to save the first file after the end of the service processing flow, and the service processing flow is ended in response to all nodes in the service processing flow being approved or one of the nodes in the service processing flow being opposed, wherein the service processing flow comprises a first node and a second node subsequent to the first node, and the service processing flow proceeds to the second node in response to the first node in the service processing flow being approved, as similarly explained in the rejection of claim 1, and is rejected under similar rationale.
With regards to claim 21, which depends on claim 1, Gazze et al, Anjum et al, Dunkley and Bacastow et al teaches wherein, the user comprises a creator of the service processing flow or a user with a predetermined management permission (as similarly explained in the rejection for claim 1, Dunkley teaches the user can manage how a file is saved by specifying a save address(see at least Fig 4)), and is rejected under similar rationale.
With regards to claim 22, which depends on claim 1, Gazze et al, Anjum et al, Dunkley and Bacastow et al wherein one of: before creating the service processing flow, in response to an operation by a user with a predetermined management permission, the target save address or a predetermined save address range of the first file is determined, or during creation of the service processing flow, the target save address of the first file is determined based on an address determined by a creator of the service processing flow from the predetermined save address range (as similarly explained in the rejection for claim 1, Dunkley teaches the user can manage how a file is saved by specifying a save address(see at least Fig 4)), and is rejected under similar rationale.
Claim(s) 6 and 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Gazze et al (“WorkMail: Collaborative Document Workflow Management by Email”, publisher: Springer-Verlag Berlin Heidelberg, published: 2012, pages 14-23) in view of Anjum et al (US Application: US 2022/0138161, filed: Oct. 30, 2020) in view of Dunkley (US Application: US 20060288222, published: Dec. 21, 2006, filed: Jun. 1, 2006) in view of Bacastow et al (US Application: US 2005/0228836, published: Oct. 13, 2005, filed: Apr. 8, 2005) and in view of Tonnison et al (US Application: US 2008/0046518, published: Feb. 21, 2008, filed: Aug. 16, 2006)
With regards to claim 6. The method of claim 5, the combination of Gazze et al, Anjum et al, Dunkley and Bacastow et al teaches wherein, the first information … configured to display the all or part of the service processing flow information after being triggered, as similarly explained in the rejection of claim 1 (information such as workflow state, notes/opinions, and approval status can be triggered by a user for display or triggered based upon receipt of the email with attached document from a sender), and is rejected under similar rationale.
However the combination as explained in the rejection of claim 1 does not expressly teach … comprises link information; and the link information is configured to display the all or part of the service processing flow information after being triggered.
Yet Tonnison et al also teaches … comprises link information; and the link information is configured to display the all or part of the service processing flow information after being triggered (paragraphs 0119 and 0120: the first information includes link information for which the recipient clicks on in the email, which is configured to launch a determined office application interface with the email interface (the email interface including display of additional service/workflow information).
It would have been obvious to one of ordinary skill in the art before the effective filing of the invention to have modified the combination of Gazze et al, Anjum et al, Dunkley and Bacastow et al’s ability to display first information at a file position in an interface, such that the displayed first information could have included a link for a recipient to click on and display service processing flow/workflow information after being triggered by the link interaction, as taught by Tonnison et al. The combination would have efficiently organized and displayed up to date email and office action documents for an individual’s mailbox (Tonnison et al, Abstract).
With regards to claim 12. The method of claim 1, Gazze et al, Anjum et al, Dunkley and Bacastow et al teaches wherein determining service processing flow information of the first application, and displaying first information at a predetermined position in the first file, as similarly explained in the rejection of claim 1, and is rejected under similar rationale.
However the combination explained in the rejection of claim 1 does not expressly teach … in response to an update of service processing progress of the first application, updating the first information, and displaying updated first information or link information of the updated first information at a predetermined position in the first file, the link information being configured to display the updated first information after being triggered.
Yet Tonnison et al teaches … in response to an update of the service processing progress of the first application, updating the first information, and displaying the updated first information or link information of the updated first information at a predetermined position in the first file, the link information being configured to display the updated first information after being triggered (paragraphs 0113, 0119 and 0120: a user can edit/update a document and make/impact changes to a workflow via approval opinion and document attributes, such that the changes are sent to the email server (online database), and an updated link can be sent/provided to other recipients to reference the latest document in an interface that includes additional first information (such as Fig. 23, which shows latest notes/opinions/properties)).
It would have been obvious to one of ordinary skill in the art before the effective filing of the invention to have modified Gazze et al, Anjum et al, Dunkley and Bacastow et al s ability to determine service processing flow information and displaying first information, such that the first information can be updated and displayed based upon user interaction (triggering) the link, as taught by Tonnison et al. The combination would have allowed Gazzè et al, Anjum et al and Dunkley to have maintained a neat email account, eliminated the manual deletion of old version emails, made it easier for finding the latest version email, and … reduced the storage space (Tonnison et al, paragraph 0023).
Claim(s) 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Gazze et al (“WorkMail: Collaborative Document Workflow Management by Email”, publisher: Springer-Verlag Berlin Heidelberg, published: 2012, pages 14-23) in view of Anjum et al (US Application: US 2022/0138161, filed: Oct. 30, 2020) in view of Dunkley (US Application: US 20060288222, published: Dec. 21, 2006, filed: Jun. 1, 2006) in view of Bacastow et al (US Application: US 2005/0228836, published: Oct. 13, 2005, filed: Apr. 8, 2005) and in view of Argent (US Application: US 2013/0283145, published: Oct. 24, 2013, filed: Apr. 10, 2013)
With regards to claim 9. The method of claim 1, Gazze et al, Anjum et al, Dunkley and Bacastow et al teaches wherein determining service processing flow information of the first application, and displaying first information at a predetermined position in the first file comprises: in response to end of the service processing flow corresponding to the first file, determining the service processing flow information of the first application, , as similarly explained in the rejection of claim 1 (as explained, Gazzè et al teaches workflow processing is performed for a first email application and Gazzè et al’s email application’s interface was modified to display first information at a position of the first email file in response to retrieving/processing workflow information and other information (such as notes or approval/opinions for display (positioned in a display of first file information). Dunkley was also explained in the rejection of claim 1 that at ten end of the file’s processing flow, determining the service flow information for saving), and is rejected under similar rationale.
However, although the combination teaches in response to the end … and displaying the first information at the predetermined position in the first file.
Yet Argent teaches in response to the end … and displaying the first information at the predetermined position in the first file (Abstract, Fig. 2,
Fig. 5, paragraph 0080: in response to an end state of reading, a position is saved and the position can be restored).
It would have been obvious to one of ordinary skill in the art before the effective filing of the invention to have modified Gazze et al, Anjum et al, Dunkley and Bacastow et al’s to display information in response to processing of steps in a workflow/service-flow of a file, such that the position information could be restored upon revisiting the file, as taught by Argent. The combination would have allowed Gazzè et al, Anjum et al et al and Dunkley to have accurately restored a position within an electronic document (Argent, paragraph 0015) .
Claim(s) 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Gazze et al (“WorkMail: Collaborative Document Workflow Management by Email”, publisher: Springer-Verlag Berlin Heidelberg, published: 2012, pages 14-23) ) in view of Anjum et al (US Application: US 2022/0138161, filed: Oct. 30, 2020) in view of Dunkley (US Application: US 20060288222, published: Dec. 21, 2006, filed: Jun. 1, 2006) in view of Bacastow et al (US Application: US 2005/0228836, published: Oct. 13, 2005, filed: Apr. 8, 2005) in view of Chumakova (“How to Transform your Outlook into a Workflow System”, published: January 2015, pages 1-4)
With regards to claim 11. The method of claim 1 Gazze et al, Anjum et al, Dunkley and Bacastow et al teaches wherein the first information is displayed … of the first document, as similarly explained in the rejection of claim 1, and is rejected under similar rationale.
However the combination does not expressly teach …. displayed between a title and a body of a first document.
Yet Chumakova teaches …. displayed between a title and a body of the first document (page 2: a title/subject of a first workflow document/task is displayed and a large text field at the bottom is the body for the task and in between the title/subject and body field are attachments and workflow service data that includes workflow status ‘in progress’).
It would have been obvious to one of ordinary skill in the art before the effective filing of the invention to have modified Gazze et al, Anjum et al, Dunkley and Bacastow et al’s ability to display first information of the first document in an interface, such that the interface could have been modified to display service information in between a title and a body of the first document, as taught by Chumakova. The combination would have allowed efficient team collaboration through automatic routing and easier document tracking (Chumakova, page 2)
Response to Arguments
Applicant's arguments filed 12/22/2025 have been fully considered but they are not persuasive.
With regards to claim 1, the applicant addresses Tonnison for failing to teach the newly amended items. In view of applicant’s amendments in the claim, Tonnison is withdrawn for claim 1 and Anjum et al that was filed from applicant’s filed IDS (IDS filed on: 12/08/2025) is now applied in a new combination Gazze et al, Anjum et al, Dunkley et al and Bacastow et al to teach the applicant’s newly amended limitations of claim 1. The examiner respectfully directs applicant’s attention to the rejection of claim 1 above for an explanation as to how Anjum et al is applied in the combination to reject the limitations of newly amended claim 1.
With regards to independent claims 19 and 20, the applicant argues they are allowable for reasons explained by the applicant for claim 1. However, this argument is not persuasive since claim 1 has been shown/explained to be rejected under the new combination of Gazze et al, Anjum et al, Dunkley et al and Bacastow et al.
With regards to the dependent claims, the applicant argues they are allowable for reasons presented by the applicant for their dependency upon one of their corresponding independent claims. However this argument is not persuasive since the independent claims have been shown/explained to be rejected above.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to WILSON W TSUI whose telephone number is (571)272-7596. The examiner can normally be reached Monday - Friday 9 am -6 pm.
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, Adam Queler can be reached at (571) 272-4140. 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.
/WILSON W TSUI/Primary Examiner, Art Unit 2172
Prosecution Insights