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 .
Claims 1-7 and 10-22 are pending.
Claims 1, 2, and 14-16 are amended.
Claims 8 and 9 were previously cancelled.
Response to Arguments
Applicant’s amendments, filed June 25, 2025, with regards to Section 101 have been fully considered but and are persuasive. That is, the argument that the newly recited additional elements, which also emphasize the practical application of the claims are technical in nature and integrates a judicial exception into a practical application. As such, the rejection is withdrawn.
Applicant’s arguments with respect to the Section 103 rejections have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Objections
Claims 1, 14, and 15 are objected to because of the following informalities: the claims recite “generating, a central server location,…”. This phrase is non-idiomatic and is assumed for the purposes of examination to be a typographical error that should read “generating, at a central server location, …”. Appropriate correction is required.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-7, 10, 12-20 and 22 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Application Publication No. 20160182412 to Kabbes et al. in view of “Request for Comments: 2822” (hereinafter RFC2822) and U.S. Patent Application Publication No. 20210149914 to Busch et al.
With regards to claims 1, 14, and 15, Kabbes et al. teaches
generating, [at] a central server location (paragraph [0124], “The user experience can be implemented using various processes on a client (e.g., client 202 or 206 of FIG. 2) and a server (e.g., message management service 200).”, and paragraph [0155]), a collaboration object having a plurality of fields comprising at least a draft collaborator field for holding identifiers of collaborating users (paragraph [0006], “Certain embodiments of the present invention provide collaborative drafting of messages, including but not limited to email messages. A “creating” user who is drafting a message can, at any point, decide to make the draft a “collaborative draft.” To do so, the creating user can identify one or more other users as “collaborating users” (also referred to as “collaborators”).”)
a respective approval flag for each collaborating user indicated in the draft collaborator field that is assertable to indicate that a respective collaborating user approves of the collaboration object (paragraph [0139], “The approval metadata can be stored, e.g., in author information table 450 of FIG. 4. For example, the entry for each author can include an approval flag that indicates whether the author has approved the current draft.”; paragraph [0141], “If, at block 1706, not all authors have approved the draft, then at block 1712, other authors can be notified of the approval by one author. For instance, updated metadata including the approval flags can be sent to the clients of the other authors.”), and
a draft message field for holding email content (paragraph [0006], “For example, the creating user can operate a client of a message management service to draft the message. The client interface can provide user-operable controls via which the creating user can identify the collaborating users and send an instruction to the message management service to create a collaborative draft.”)
in response to input from the first user, populating at least the draft collaborator field with an identifier of a second user (paragraph [0006], “The client interface can provide user-operable controls via which the creating user can identify the collaborating users and send an instruction to the message management service to create a collaborative draft. The message management service can generate invitations to the identified collaborating users. A collaborating user who accepts can thereby become an author of the message, along with the creating user.”);
providing the collaboration object to enable the second user to make modifications to one or more of the plurality of fields of the collaboration object to generate a modified version of the collaboration object (paragraph [0006], “The authors can collaborate to edit the message using various real-time and/or non-real-time techniques for collaborative editing supported by the message management service. When the authors determine that the message is ready to be sent, one (or all) of them can so instruct the message management service.”), …;
generating the final email based on the modified version of the collaboration object by (paragraph [0109], “In some embodiments, screen 1000 can support real-time collaboration among authors. For instance, if other authors are also editing the draft, their edits can be shown in real time on screen 1000. For instance, at location 1030, it is indicated that collaborator Brad is typing the text “task6” while the user viewing screen 1000 is typing at the location of cursor 1022. Each author's edits can be shown in a distinctive font or color (underlining and italics are used in FIG. 10, but other distinguishing characteristics can be used), and callouts such as callout 1032 can identify which author is making the edits. Conventional or other techniques for communicating edits and updates to a document between devices in real time can be used.”):
populating the From field of the final email with an identifier of the first user (paragraph [0101], “For each message, e.g., message 804, list 802 can present a preview representation that can include “from” information 810 identifying the sender(s) of message 804, subject line 812, and content preview 814, which can include a portion of the message content.”; “Sender” header 1103 and “From” header 1104 can be populated with an identifier of the author who actually sent the message (e.g., the user who operated send control 1040.”);
populating the collaborator field of the final email with an identifier of the second user (paragraph [0118], “In this example, “From” header 1150 can exploit the IETF RFC 5322 email standard, which specifies that the “From” header can include multiple email addresses. In some embodiments, the recipient's email client can present the multiple addresses.”);
populating the To field with an identifier of a primary recipient (paragraph [0105], “The information can include a list of collaborators 912, identifier(s) of the intended recipient(s) 914 (which in some embodiments can include a “To” line as shown, a “CC” line and a “BCC” line), and a subject line 916.”);
populating the CC field with an identifier of a secondary recipient (paragraph [0105], “The information can include a list of collaborators 912, identifier(s) of the intended recipient(s) 914 (which in some embodiments can include a “To” line as shown, a “CC” line and a “BCC” line), and a subject line 916.”); and
populating the message field of the final email with email content as present in the draft message field of the modified version of the collaboration object (paragraph [0110], “For instance, an author may be able to insert comments into the draft that are visible to other authors, who can review and respond, but that are not included in the final message as sent. Some interfaces can provide an interactive chat feature to allow authors to chat with each other about the draft while they are editing, and so on.”; paragraph [0115], “When a collaborative message is sent, the message headers and/or message body can be modified to indicate that the message has multiple authors. FIGS. 11A and 11B show pseudocode examples of incorporating identifiers of multiple authors into an email message according to an embodiment of the present invention.”); and
in response to determining that approval flags for all of the collaborating users are asserted (claim 12, “determine whether the approval metadata indicates that instructions to send the message have been received from all of the authors, wherein sending of the updated draft message to the message recipient occurs in response to determining that the approval metadata indicates that instructions to send the message have been received from all of the authors.”; paragraph [0010], “In some embodiments, a message can be sent when one author approves or when all the authors approve. Other criteria can also be specified. For purposes of sending the message, the server can select one of the authors (e.g., the creating user) to be treated as the message sender.”; paragraph [0139], “The approval metadata can be stored, e.g., in author information table 450 of FIG. 4. For example, the entry for each author can include an approval flag that indicates whether the author has approved the current draft.”),
automatically transmitting the final email to the primary recipient and the secondary recipients (Fig. 17, paragraph [0140], “At block 1706, process 1700 can determine whether all authors have approved the draft message, e.g., by inspecting the approval metadata. If so, then at block 1708, the draft message can be sent to the designated recipient(s). Sending the draft as a message can include, e.g., identifying a current version of the draft, formatting the message content, creating headers to identify the authors and recipient(s), etc. At block 1710, process 1700 can notify all authors that the draft message has been sent.”), the final email comprising: the From field populated with the identifier of the first user (paragraph [0101], “For each message, e.g., message 804, list 802 can present a preview representation that can include “from” information 810 identifying the sender(s) of message 804, subject line 812, and content preview 814, which can include a portion of the message content.”; “Sender” header 1103 and “From” header 1104 can be populated with an identifier of the author who actually sent the message (e.g., the user who operated send control 1040.”); the collaborator field populated with the identifier of the second user (paragraph [0118], “In this example, “From” header 1150 can exploit the IETF RFC 5322 email standard, which specifies that the “From” header can include multiple email addresses. In some embodiments, the recipient's email client can present the multiple addresses.”); the To field populated with the identifier of the primary recipient; the CC field populated with the identifier of the secondary recipient (paragraph [0082], “For instance, recipient information 420 can include an email address of each recipient. In some embodiments, recipients can be designated as “To,” “CC,” and “BCC” recipients (per a standard email convention).”); and the message field populated with the email content as present in the draft message field of the modified version of the collaboration object (paragraph [0083], “Message body 422 can include the current version of the content of the message.”). It is noted that the only apparent difference between the From field in Kabbes et al. and the claimed collaborator fields seems to be the naming conventions, but Kabbes et al. may be said to fail to explicitly teach a collaborator field independent from the To field. However, RFC2822 teaches
to the primary recipient and the secondary recipients the final email comprising: the From field populated with the identifier of the first user; the collaborator field populated with the identifier of the second user (Section 3.6.2. Originator fields, “The originator fields of a message consist of the from field, the sender field (when applicable), and optionally the reply-to field. The from field consists of the field name "From" and a comma-separated list of one or more mailbox specifications. If the from field contains more than one mailbox specification in the mailbox-list, then the sender field, containing the field name "Sender" and a single mailbox specification, MUST appear in the message.” and “The originator fields indicate the mailbox(es) of the source of the message. The "From:" field specifies the author(s) of the message, that is, the mailbox(es) of the person(s) or system(s) responsible for the writing of the message. The "Sender:" field specifies the mailbox of the agent responsible for the actual transmission of the message.”).
This part of RFC2822 is applicable to the system of Kabbes et al. as they both share characteristics and capabilities, namely, they are directed to email addressing from multiple authors. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Kabbes et al. to include the conventionally named "From:" field that specifies the author(s) as taught by RFC2822 as the collaborators field and "Sender:" field as taught by RFC2822 that specifies the mailbox of the agent responsible for the actual transmission of the message as the From field for the instant claims. One of ordinary skill in the art before the effective filing date of the claimed invention would have been motivated to modify Kabbes et al. in order to comply with an Internet standards track protocol for the Internet community conventions in order to provide interoperable email solutions (see Status of this memo and Abstract of RFC2822).
Kabbes et al. teaches the collaboration object is not sent to a user device of the second user (paragraph [0056], “Draft cache 230 can be a database or other data store that provides storage and retrieval of one or more draft messages, including collaborative draft messages. For example, a draft message can be stored and retrieved by reference to document identifiers assigned to each draft by message management service 200. In some embodiments, the draft message can be stored in association with version information that indicates a version of the draft, e.g., to facilitate synchronization across clients, including clients belonging to different users.”), but fails to explicitly teach the providing a network address of the collaboration object. However, Busch et al. teaches
the collaboration object is not sent to a user device of the second user (paragraph [0037], “To share a content item privately, sharing module 130 can be configured to add a user account identifier to the content entry associated with the content item, thus granting the added user account access to the content item. Sharing module 130 can also be configured to remove user account identifiers from a content entry to restrict a user account's access to the content item.”; paragraph [0038], “To share content publicly, sharing module 130 can be configured to generate a custom network address, such as a uniform resource locator (URL), which allows any web browser to access the content in content management system 106 without any authentication. To accomplish this, sharing module 130 can be configured to include content identification data in the generated URL, which can later be used to properly identify and return the requested content item.”), and
wherein the collaboration object is provided to the second user by providing a network address of the collaboration object at the central server location to the second user for the second user to access and modify the collaboration object (paragraph [0038], “To share content publicly, sharing module 130 can be configured to generate a custom network address, such as a uniform resource locator (URL), which allows any web browser to access the content in content management system 106 without any authentication. To accomplish this, sharing module 130 can be configured to include content identification data in the generated URL, which can later be used to properly identify and return the requested content item. For example, sharing module 130 can be configured to include the user account identifier and the content path in the generated URL. Upon selection of the URL, the content identification data included in the URL can be transmitted to content management system 106 which can use the received content identification data to identify the appropriate content entry and return the content item associated with the content entry.”; paragraph [0039], “In addition to generating the URL, sharing module 130 can also be configured to record that a URL to the content item has been created. In some embodiments, the content entry associated with a content item can include a URL flag indicating whether a URL to the content item has been created. For example, the URL flag can be a Boolean value initially set to 0 or false to indicate that a URL to the content item has not been created. Sharing module 130 can be configured to change the value of the flag to 1 or true after generating a URL to the content item.”);
This part of Busch et al. is applicable to the system of Kabbes et al. as they both share characteristics and capabilities, namely, they are directed to email addressing from multiple authors. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Kabbes et al. to include the network address provisioning as taught by Busch et al. One of ordinary skill in the art before the effective filing date of the claimed invention would have been motivated to modify Kabbes et al. in order to take advantage of the content management system's functionality to manage and synchronize content items while also providing the collaboration functionality of the content collaboration system (see paragraph [0004] of Busch et al.).
With further regards to claim 14 Kabbes et al. teaches a computer program comprising instructions such that when the computer program is executed on one or more computing devices, the one or more computing devices are arranged to carry out a method of generating a final email (paragraph [0159] et seq., “In some embodiments, local storage 1806 can store one or more software programs to be executed by processing unit(s) 1804, such as an operating system and/or programs implementing various server functions such as functions of message management modules 212, messaging service interface 214, and/or client interface 210 of FIG. 2, or any other server(s) associated with messaging system 100 of FIG. 1. “Software” refers generally to sequences of instructions that, when executed by processing unit(s) 1804 cause server system 1800 (or portions thereof) to perform various operations, thus defining one or more specific machine implementations that execute and perform the operations of the software programs.”), and with regards to claim 15 Kabbes et al. teaches a user device comprising a processing system constructed and arranged to carry out a method of generating a final email (paragraph [0155] et seq., “FIG. 18 shows a simplified block diagram of a representative server system 1800 and client computer system 1814 usable to implement certain embodiments of the present invention. In various embodiments, server system 1800 or similar systems can implement message management service 200, messaging services 204, or any other services or servers described herein or portions thereof. Client computer system 1814 or similar systems can implement client device 202, 206, or other clients described herein.”).
With regards to claims 2 and 16, Kabbes et al. teaches providing the collaboration object comprises emailing the collaboration object to a user device of the second user (paragraph [0087], “Collaborative drafts and non-collaborative drafts can be made available through the same drafts folder and managed similarly; for instance, a collaborative draft can be made available through the drafts folder of each author and can be automatically removed from the drafts folders of all authors upon sending the draft message to the recipient(s). Thus, in some embodiments, existing user interfaces can be enhanced to support various features of collaborative drafts.”); and
wherein the modified version of the collaboration object is received via email (paragraph [0087], “Collaborative drafts and non-collaborative drafts can be made available through the same drafts folder and managed similarly; for instance, a collaborative draft can be made available through the drafts folder of each author and can be automatically removed from the drafts folders of all authors upon sending the draft message to the recipient(s). Thus, in some embodiments, existing user interfaces can be enhanced to support various features of collaborative drafts.”) but fails to explicitly teach the providing a network address of the collaboration object. However, Busch et al. teaches.
providing the collaboration object comprises emailing the network address of the collaboration object to the user device of the second user (paragraph [0071], “In some embodiments, system 300 can include user device 310. For example, user device 310 can be a device of another user (e.g., second user) with which document reference 212 has been shared. The user (e.g., first user) of user device 230 may have, for example, sent document reference 212 to the second user in an email message, instant message, or using some other electronic communication mechanism.”); and
wherein, upon generating the modified version of the collaboration object based on input from the second user, allowing access to the modified version of the collaboration object via the network address (paragraph [0024], “The content can also include collections for grouping content items together with different behaviors, such as folders, playlists, albums, etc. For example, an account can include a public folder that is accessible to any user. The public folder can be assigned a web-accessible address. A link to the web-accessible address can be used to access the contents of the public folder.”; paragraph [0045], “In some embodiments, web browser 232 can receive web page 233 from collaboration system 222 that allows the user to create, modify, delete, rename, etc., documents (e.g., document 224) managed by collaboration system 222.”).
This part of Busch et al. is applicable to the system of Kabbes et al. as they both share characteristics and capabilities, namely, they are directed to email addressing from multiple authors. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Kabbes et al. to include the network address provisioning as taught by Busch et al. One of ordinary skill in the art before the effective filing date of the claimed invention would have been motivated to modify Kabbes et al. in order to take advantage of the content management system's functionality to manage and synchronize content items while also providing the collaboration functionality of the content collaboration system (see paragraph [0004] of Busch et al.).
With regards to claims 3 and 17, Kabbes et al. teaches the modified version of the collaboration object is received following a collaboration stage in which the collaboration object is sent to at least two collaborating users (paragraph [0087], “Collaborative drafts and non-collaborative drafts can be made available through the same drafts folder and managed similarly; for instance, a collaborative draft can be made available through the drafts folder of each author and can be automatically removed from the drafts folders of all authors upon sending the draft message to the recipient(s). Thus, in some embodiments, existing user interfaces can be enhanced to support various features of collaborative drafts.”).
With regards to claims 4 and 18, Kabbes et al. teaches the collaboration object comprises a draft To field for holding identifiers of primary recipients of the final email (paragraph [0095], “The user can position a cursor element 607 in header region 602 or composition region 604 and type on virtual keyboard 606 to add information to the draft. For example, the user can populate “To” field 608 with one or more recipient identifiers and “Subject” field 610 with a subject line.”); and
populating the To field with the identifier of the primary recipient is based on the draft To field of the modified version of the collaboration object (paragraph [0095], “The user can position a cursor element 607 in header region 602 or composition region 604 and type on virtual keyboard 606 to add information to the draft. For example, the user can populate “To” field 608 with one or more recipient identifiers and “Subject” field 610 with a subject line.”).
With regards to claims 5 and 19, Kabbes et al. teaches the collaboration object comprises a draft CC field for holding identifiers of secondary recipients of the final email (paragraph [0095], “In some embodiments, the user may be able to access a contacts list (e.g., address book) and/or exploit an autocompletion feature of the client app to facilitate identifying recipients. Additional options for designating recipients (e.g., “CC” and/or “BCC” fields) can also be provided.”); and
populating the CC field with the identifier of the secondary recipient is based on the draft CC field of the modified version of the collaboration object (paragraph [0095], “In some embodiments, the user may be able to access a contacts list (e.g., address book) and/or exploit an autocompletion feature of the client app to facilitate identifying recipients. Additional options for designating recipients (e.g., “CC” and/or “BCC” fields) can also be provided.”).
With regards to claims 6 and 20, Kabbes et al. teaches the collaboration object but fails to explicitly teach a collaborator field independent from the To field. However, Bhogal et al. teaches
a draft optional collaborator field for holding identifiers of one or more optional collaborator (paragraph [0051], “Each record in the collaborator copy table 410 represents a copy of a collaborative email document provided to a collaborator for viewing and editing. Each record in the collaborator copy table 410 includes an identification 412 of the collaborator to whom a copy was provided. The collaborator identification 412 may be implemented as, for example, a collaborator's email address. Each collaborator copy record 410 also includes a document identification field 404 identifying the document a copy of which was provided to the collaborator.”);
the method comprises identifying which of the one or more optional collaborators made at least one modification to the collaboration object (paragraph [0070], “The method of FIG. 5 also includes providing 506 to the collaborators copies of the document for viewing and editing, and the collaborators' copies typically reside on collaborators' clients while the document is being written. In the metadata example, Mary Johnson, the administrator for the document, is also identified as a collaborator, which is optional.”); and
generating the final email comprise populating the collaborator field of the final email with optional collaborators as present in the draft optional collaborator field of the modified version of the collaboration object who made at least one modification to the collaboration object (paragraph [0076], “Similarly, in response to the data communications transmission carrying the revisions of a version to a server, a server using server-side data structures like those of FIG. 4 is programmed to update the pertinent collaborator copy record 410 with a new version number 414 for the collaborator copy where the new version was created. Such a server then creates a revision record 422 for each revision comprising the new version of the document.”).
This part of Bhogal et al. is applicable to the system of Kabbes et al. as they both share characteristics and capabilities, namely, they are directed to collaborative object creation. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Kabbes et al. to include the collaborators field as taught by Bhogal et al. One of ordinary skill in the art before the effective filing date of the claimed invention would have been motivated to modify Kabbes et al. in order to allow for clear identification of delegable authorities for signing, viewing, and editing collaborative email documents (see paragraph [0003] of Bhogal et al.).
With regards to claim 7, Kabbes et al. teaches transmitting the final email to the second user (paragraph [0087], “Collaborative drafts and non-collaborative drafts can be made available through the same drafts folder and managed similarly; for instance, a collaborative draft can be made available through the drafts folder of each author and can be automatically removed from the drafts folders of all authors upon sending the draft message to the recipient(s).”).
With regards to claim 10, Kabbes et al. teaches the respective approval flag for a collaborating user is automatically asserted in response to that collaborating user sending the collaboration object (paragraph [0139], “At block 1702, message management service 200 can receive a “send” instruction from a client of one of the authors. At block 1704, process 1700 can update metadata for the draft that indicates which authors have approved. The approval metadata can be stored, e.g., in author information table 450 of FIG. 4. For example, the entry for each author can include an approval flag that indicates whether the author has approved the current draft.”).
With regards to claims 12 and 22, Kabbes et al. teaches the respective approval flag for a collaborating user is automatically asserted in response to user input from that collaborating user (paragraph [0141], “For instance, updated metadata including the approval flags can be sent to the clients of the other authors. The clients can present this information to the authors using various techniques, including pop-up notifications, showing a comment in the draft, visually highlighting the names of authors who have approved (e.g., changing the font color of the approving author's name in collaborators line 1002 of FIG. 10, adding a check mark or other visual cue next to each author who has approved, or the like)”).
With regards to claim 13, Kabbes et al. teaches modifications to the collaboration object made by a collaborating user are indicated visually in the collaboration object (paragraph [0141], “For instance, updated metadata including the approval flags can be sent to the clients of the other authors. The clients can present this information to the authors using various techniques, including pop-up notifications, showing a comment in the draft, visually highlighting the names of authors who have approved (e.g., changing the font color of the approving author's name in collaborators line 1002 of FIG. 10, adding a check mark or other visual cue next to each author who has approved, or the like)”).
Claims 11 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Application Publication No. 20160182412 to Kabbes et al. in view of “Request for Comments: 2822” (hereinafter RFC2822) and U.S. Patent Application Publication No. 20210149914 to Busch et al. as applied to claims 1-7, 10, 12-20 and 22 above, and further in view of U.S. Patent Application Publication No. 20120323842 to Izhikevich et al.
With regards to claims 11 and 21, Kabbes et al. teaches the respective approval flag for a collaborating user, but fails to explicitly teach a time limit for approval flags. However Izhikevich et al. teaches the approval flag for a collaborating user is automatically asserted in response to expiry of a predefined time limit following that collaborating user receiving the collaboration object (paragraph [0021], “In another embodiment of the architecture, each article has a curator and one or more assistants associated therewith; and modifications to each article made by the one or more assistants are approved by the relevant curator by either (i) affirmative approval; or (ii) tacit approval.”; paragraph [0022], “In one variant, the tacit approval comprises expiration of a predetermined period of time without an affirmative approval (i).”).
This part of Izhikevich et al. is applicable to the system of Kabbes et al. as they both share characteristics and capabilities, namely, they are directed to collaborative object creation. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Kabbes et al. to include the approval time limits as taught by Izhikevich et al. One of ordinary skill in the art before the effective filing date of the claimed invention would have been motivated to modify Kabbes et al. in order to avoid bottlenecks in review processess (see paragraphs [0036]-[0040] of Izhikevich et al.).
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 Joshua D Schneider whose telephone number is (571)270-7120. The examiner can normally be reached on Monday - Friday, 9am-5pm.
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, Jessica Lemieux can be reached on (571)272-6782. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/J.D.S./Examiner, Art Unit 3626
/JESSICA LEMIEUX/Supervisory Patent Examiner, Art Unit 3626