DETAILED ACTION
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 .
Response to Amendment
This Action is in response to amendments/ remarks filed on 01/16/2026.
Independent claims 1, 8 and 13 have been amended. There are no new/canceled claims.
Claims 1-20 are presented for examination, and remain pending in this application.
Response to Arguments Regarding Claim Objections
In the non-final office Action mailed on 10/21/2025, claims 1, 8 and 13 were objected to due to minor informalities. In the response filed on 01/16/2026, applicant amends the respective claims to obviate the objections. These amendments are acceptable, and as a result, the respective claim objections made in the non-final Office Action have been withdrawn.
Response to Arguments Regarding Double Patenting Rejections
In the non-final office Action mailed on 10/21/2025, Claims 1-20 were rejected on the ground of non-statutory double patenting as being unpatentable over claims of U.S. Patent No. US 9917702 B2 and U.S. Patent No. US 12063577 B2. In the remarks filed on 01/16/2026, applicant requests that this rejection be held in abeyance (see page 7 of REMARKS). As such, Double Patenting Rejections persists.
Response to Arguments Regarding Claim Rejections - 35 USC § 103
The Applicant's amendment/arguments, see page 7-10 of REMARKS, filed 01/16/2026, against the cited reference to Herrero regarding the new limitations in claims 1, 8 and 13 with respect to Claim Rejections- 35 USC §103 have been considered but are moot because the new ground of rejection does not rely on the reference to Herrero for any teaching or matter specifically challenged in the argument.
The Applicant's remaining amendment/arguments, see page 7-10 of REMARKS, filed 01/16/2026, with respect to Claim Rejections- 35 USC §103 have been fully considered but they are not persuasive. In the response filed on 01/16/2026, applicant puts forth in substance that:
“Without conceding the contention of the Office Action, Applicant respectfully submits that Herrero, whether considered alone or in combination with any other references, has not been shown to teach or suggest "wherein the portion of the list of shared data items from the mobile device and other portions of the list of shared data item from other mobile devices in the group each comprise data indicating respective recent update information for the shared data items," as recited in amended claim 1.
Herrero, for example, states the following:
…
The Office Action alleges that the above disclosure of Herrero teaches "sending, by the mobile device, a portion of the list of shared [data] items to the new mobile device." However, even assuming arguendo Herrero teaches these features (which Applicant does not concede), Herrero still fails to teach or suggest "wherein the portion of the list of shared data items from the mobile device and other portions of the list of shared data item from other mobile devices in the group each comprise data indicating respective recent update information for the shared data items."
As noted, Herrero's system relies on a centralized task management system that (1) receives all task, project, and contact information into a central database, (2) stores and maintains those items as centralized records, and (3) pushes updates to users by transmitting reminders or presenting tasks to users. See id. Herrero also expressly states that requests to update a task are sent to the task management system, which then updates the task centrally and subsequently presents the updated task to the same or other users. See id.
In contrast, amended claim 1 requires that the distributed portions of the list from individual mobile devices each contain data indicating "respective recent update information for the shared data items." This is a distributed update-information model, not a centralized one.
Herrero contains no teaching or suggestion of such functionality. To the contrary:
" Herrero never teaches that a new mobile device receives a "portion of the list of shared data items" from one device and "other portions" from other devices.
"Herrero instead teaches that the task management system presents pending tasks to the new user and the task management system updates task status and later distributes those updates to users.
Thus, even if Herrero were interpreted as disclosing the transmission of a "portion" of task information in some form, Herrero still relies on the central task management system to maintain the authoritative version of the task list. Herrero provides no disclosure-express or implicit-of a new mobile device receiving distributed portions of recent update information obtained from multiple peer devices.
This distinction is further reinforced by the present specification, which explains that the invention provides a method for sharing data among a group of mobile devices "without requiring a database or server to centrally store the shared data," and in which "[t]he shared data is instead stored by each group member individually while controlling the manner in which the shared data is updated." Spec., [0104].
Accordingly, Herrero has not been shown to teach or suggest "wherein the portion of the list of shared data items from the mobile device and other portions of the list of shared data item from other mobile devices in the group each comprise data indicating respective recent update information for the shared data items," as recited in amended claim 1.
Applicant submits that none of the other references has been shown to remedy the above deficiencies of Herrero.
For the above reasons, Applicant respectfully requests reconsideration and allowance of amended claim 1 and its dependent claims. For similar reasons, and because they include analogous elements, Applicant respectfully requests reconsideration and allowance of amended claims 8, 13, and their respective dependent claims.” (see page X of REMARKS; internal quotations omitted).
In response to the applicant’s arguments, as set forth above, it is first reiterated that the Applicant's amendment/arguments against the cited reference to Herrero regarding the new limitation “wherein the portion of the list of shared data items from the mobile device and other portions of the list of shared data item from other mobile devices in the group each comprise data indicating respective recent update information for the shared data items” in claims 1, 8 and 13 are moot because the new ground of rejection does not rely on the reference to Herrero for any teaching or matter specifically challenged in the argument.
Applicant argues that Herrero's system relies on a centralized task management system that (1) receives all task, project, and contact information into a central database, (2) stores and maintains those items as centralized records, and (3) pushes updates to users by transmitting reminders or presenting tasks to users. However, examiner notes that “distributed update-information model” (although not claimed), as argued by the applicant, is already discloses by primary reference to Jakobson (see Fig.4C for example). The fact that the inventor has recognized another advantage which would flow naturally from following the suggestion of the prior art cannot be the basis for patentability when the differences would otherwise be obvious. See Ex parte Obiaya, 227 USPQ 58, 60 (Bd. Pat. App. & Inter. 1985). A recitation of the intended use of the claimed invention must result in a structural difference between the claimed invention and the prior art in order to patentably distinguish the claimed invention from the prior art. If the prior art structure is capable of performing the intended use, then it meets the claim.
Applicant's arguments do not comply with 37 CFR 1.111(c) because they do not clearly point out the patentable novelty which he or she thinks the claims present in view of the state of the art disclosed by the references cited or the objections made. Further, they do not show how the amendments avoid such references or objections.
Applicant further argues that Herrero never teaches that a new mobile device receives a "portion of the list of shared data items" from one device and "other portions" from other devices. More specifically, applicant argues that Herrero provides no disclosure-express or implicit-of a new mobile device receiving distributed portions of recent update information obtained from multiple peer devices.
In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “receiving a portion of the list of shared data items from one device and receiving other portions from other devices” and/or “receiving distributed portions of recent update information obtained from multiple peer devices”) are not recited in the rejected claim(s). Contrary to the alleged features, in the claims as currently amended, the mobile device only “sends a portion of the list of shared data items to the new mobile device”. Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Applicant argues that the references do not teach or suggest "wherein the portion of the list of shared data items from the mobile device and other portions of the list of shared data item from other mobile devices in the group each comprise data indicating respective recent update information for the shared data items," as recited in amended claim 1. However, examiner disagrees, as primary reference to Jakobson teaches such feature. More specifically, Jakobson discloses that a task metadata section 304 may be updated by users receiving the task record 300, as users add notes to tasks or update the completion status of tasks (see [0038]). Once any user has completed the task (in the case where the operand "any" 412a had been used); or, all users have completed the task (in the case where the operand "all" 412b had been used) the task may appear "completed" for the "view-only" users 432 and 436 (see [0061] in view of Fig.4B-4C). Furthermore, as disclosed in [0062]-[0066], IM clients 432 and 436 may receive task-records 441b and 441c, respectively, and process the received task-record and update displayed task and/or project information; clients 432 and 436 may process its received task 441b-441c and update the proper task 444 and 446 as checked-off. upon updating the task-record of an existing task, the RecordID may be kept the same, allowing recipient IMs to discern the received task as an update of an existing task).
Applicant's arguments for independent claims 8 and 13 appear to stem from the applicant's assertion that the combination of cited references fails to disclose the similarly recited limitations of claim 1. However, as set forth above, this assertion does not hold ground, and therefore, the current rejection of record for the independent claim persists.
Applicant's arguments for the dependent claims appear to stem from the applicant's assertion that the combination of cited references fails to disclose all the limitations of respective independent claims. However, as set forth above, this assertion does not hold ground, and therefore, the current rejection of record for the dependent claims persist.
Double Patenting Rejections
The non-statutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A non-statutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on non-statutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a non-statutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-20 are rejected on the ground of non-statutory double patenting as being unpatentable over claims of U.S. Patent No. US 9917702 B2 and U.S. Patent No. US 12063577 B2 in view of Zourntos et al. (hereinafter, Zourntos, US 20030100343 A1) in view of Herrero (US 20020078007 A1). Although the claims at issue are not identical, they are not patentably distinct from each other because the limitations in the instant application are obvious variation of the method claims of the U.S. Patents, as shown using representative claims of U.S. Patent No. US 9917702 B2 in the table below:
Current Application
U.S. Patent No. US 9917702 B2
Claim 1:
A method, comprising:
obtaining, by a mobile device, a list of shared data items, each data item in the list of shared data items representing a target, the list being shared amongst a group comprising a plurality of mobile devices, the group including the mobile device, and each data item in the list of shared data items comprising a first indication indicating whether the target task has been assigned to a member of the group and a second indication indicating whether the target task has been completed;
storing, by the mobile device, the list;
obtaining, by the mobile device, a common message from one of the mobile devices in the group, the common message comprising a new value for updating an existing shared data item in the list or for a new shared data item, the common message having been sent to all mobile devices in the group and indicating to all mobile devices in the group to update a locally stored version of the list;
determining, by the mobile device, whether or not the list comprises the existing shared data item;
performing one of following:
adding, by the mobile device, the new value as a new shared data item when the list does not comprise the existing shared data item, the mobile device; or
updating, by the mobile device, the list by replacing the existing shared data item with the new value when the list does comprise the existing shared data item, the mobile device; wherein the portion of the list of shared data items from the mobile device and other portions of the list of shared data item from other mobile devices in the group each comprise data indicating respective recent update information for the shared data items.
receiving, by the mobile device, a group join request from a new mobile device;
sending, by the mobile device, a confirmation to the new mobile device to confirm acceptance of the new mobile device into to the group; and
sending, by the mobile device, a portion of the list of shared data items to the new mobile device.
Claim 1:
A method of operating a mobile device, the method comprising the mobile device:
obtaining a list of shared data items, wherein each data item is a task to be completed, the list being shared amongst a group comprising a plurality of mobile devices including the mobile device;
receiving a common message prepared by one of the mobile devices in the group, the common message comprising a first modified task of at least one of the shared data items or a first new task of a new shared data item to be added to the list of shared data items;
transmitting, in response to receiving the common message, an acknowledgement to the one of the mobile devices, wherein the acknowledgement comprises an indication that the common message was received by the mobile device;
independently determining, based on the first modified task or the first new task in the common message, if the first new task or first modified task should be used for updating the list instead of a second new task or second modified task independently generated on the mobile device, without communicating with others of the plurality of mobile devices, the common message having been sent to all of the plurality of mobile devices in the group to enable all mobile devices in the group to independently update a locally stored version of the list;
in response to determining the first new task or first modified task should be used for updating the list, updating the list by one of adding the first new task to the list or replacing an existing item in the list with the first modified task and without further communication with at least the one of the mobile devices in association with the updating, wherein the list of shared data items is updated without disrupting other values in the shared data items; and
in response to determining a second new task or second modified task independently generated on the mobile device should be used for updating the list, updating the list by one of adding the second new task to the list or replacing an existing item in the list with the second modified task and without further communication with at least the one of the mobile devices in association with the updating.
Claim 3:
The method according to claim 1, wherein the at least one shared data item in the list has a user assignment to indicate who is to be completing that shared data item.
Claim 5:
The method according to claim 1, wherein the first new task or first modified task represents a task in a group project, and wherein the task comprises a plurality of values associated therewith indicative of status information for the task.
U.S. Patent No. US 9917702 B2 does not explicitly disclose receiving, by the mobile device, a group join request from a new mobile device; sending, by the mobile device, a confirmation to the new mobile device to confirm acceptance of the new mobile device into to the group; and sending, by the mobile device, a portion of the list of shared data items to the new mobile device.
However, Zourntos discloses receiving, by the mobile device, a group join request from a new mobile device (see [0710]; module to send a join mitigated group (JMG) packet to a nearby matrix node; module sends a request if it wishes to join any of the local groups); and
sending, by the mobile device, a confirmation to the new mobile device to confirm acceptance of the new mobile device into to the group (see [0710]; current members of the mitigated group to give consent to the module's request to join their mitigated group. The default security procedure requires only one user to give consent for a new user to be allowed to enter).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Zourntos with U.S. Patent No. US 9917702 B2 to receive, by the mobile device, a group join request from a new mobile device; and to send, by the mobile device, a confirmation to the new mobile device to confirm acceptance of the new mobile device into to the group.
One of ordinary skill in the art would have been motivated so that a new user is allowed to enter a group based on a request to join any of the local groups (Zourntos: see [0710]).
U.S. Patent No. US 9917702 B2 (modified by Zourntos) does not explicitly teach sending, by the mobile device, a portion of the list of shared data items to the new mobile device.
However, Herrero discloses sending, by the mobile device, a portion of the list of shared data items to the new mobile device (see [0009]; the task management system presents a pending task to the new user; also see [0010]; the task management system receives a request from the new user to update the status a pending task. The task management system updates the pending task and later presents the updated task to the same or other users; also see [0038]; Once a user has activated a new account, that user may access tasks associated with the user's e-mail address … including tasks that were created before the new user established the new account).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Herrero with U.S. Patent No. US 9917702 B2 and Zourntos to send, by the mobile device, a portion of the list of shared data items to the new mobile device.
One of ordinary skill in the art would have been motivated to encourage cooperative action as between various team members (Herrero: see [0053]).
Claim 2:
The method according to claim 1, wherein the common message is obtained from a message exchange service.
Claim 2:
The method according to claim 1, wherein the common message is obtained from a message exchange service
Claim 3:
The method according to claim 1, wherein the shared data items are stored as records in a database as shared data stored individually by each member of the group.
Claim 15:
… list of shared data items…
the new task being generated by the mobile device modifying an existing record in a database to update a corresponding task; sending the common message to the other mobile devices in the group to enable the other mobile devices to independently update the locally stored version of the list…
Claim 4:
The method according to claim 1, further comprising generating, by the mobile device, an updated list to reflect changes made by the other mobile devices in the group.
Claim 4:
The method according to claim 1, further comprising generating an updated list to reflect changes made by the other mobile devices in the group.
Claim 5:
The method according to claim 1, wherein the new value represents a task in a group project, and wherein the task comprises a plurality of values associated therewith indicative of status information for the task.
Claim 5:
The method according to claim 1, wherein the first new task or first modified task represents a task in a group project, and wherein the task comprises a plurality of values associated therewith indicative of status information for the task.
Claim 6:
The method according to claim 1, further comprising posting a comment pertaining to a selected one or more of the shared data items.
Claim 6:
The method according to claim 1, further comprising posting a comment pertaining to a selected one or more of the shared data items.
Claim 7:
The method according to claim 1, wherein at least one shared data item in the list has a user assignment to indicate who is to be completing that shared data item.
Claim 9:
The non-transitory computer readable medium according to claim 7, wherein the at least one shared data item in the list has a user assignment to indicate who is to be completing that shared data item.
Claim 10:
The method according to claim 8, comprising:
generating, by the mobile device, a list of shared data items, each data item in the list of shared data items representing a task to be completed, the list being shared amongst a group comprising a plurality of mobile devices, the group including the mobile device;
wherein the method further comprising:
sharing, by the mobile device, the list with the other mobile devices in the group to enable all mobile devices in the group to track status of and apply updates to the list.
Claim 17:
A method of operating a mobile device, the method comprising the mobile device:
generating a list of shared data items, each data item representing a task to be completed, the list being shared amongst a group comprising a plurality of mobile devices including the mobile device;
sharing the list with the other mobile devices in the group to enable all mobile devices in the group to maintain a locally stored version of the list;…
updating the locally stored version of the list,…
Claim 5:
The method according to claim 1, ….indicative of status information for the task.
Claim 12:
The method according to claim 10, wherein the list is shared amongst only a subset of the group of mobile devices.
Claim 21:
The method according to claim 17, wherein the list is shared amongst only a subset of the group of mobile devices.
Regarding independent claims 8 and 13, although the claims at issue are not identical, they are obvious variants of each other, and are not patentably distinct from each other because all of the limitations of the claims in the instant application are met with respect to claims of the U.S. Patent No. US 9917702 B2. In addition, the U.S. Patent No. US 9917702 B2 discloses corresponding method claims (Claims 1, 13 and 17) and non-transitory computer readable storage medium claim (Claims 7, 15 and 22).
Regarding dependent claims 9, 11 and 14-20, although the claims at issue are not identical, they are obvious variants of each other, and are not patentably distinct from each other because all of the limitations of the claims in the instant application are met with respect to claims of the U.S. Patent No. US 9917702 B2 as set forth above. In addition, these claims themselves do not teach or further define over the limitations in claims 2-7 and 10 of instant application. Therefore, they are rejected for the same reasons as set forth in claims 2-7 and 10.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Jakobson (US 20080209417 A1) in view of Zourntos et al. (hereinafter, Zourntos, US 20030100343 A1) in view of Herrero (US 20020078007 A1).
Regarding claim 1, Jakobson teaches a method, comprising:
obtaining (Fig.1:108), by a mobile device (Fig.1:102), a list of shared data items (see [0016]; IM application, running on an electronic device, may allow a user to create, assign, track, view, export, import and manage tasks; IM applications may include cellular phone modules; also see [0020]; IM application 102 may import 108 a project record exported from a PMA 100. Once the project record is imported, IM application 102 may share 110 projects and tasks defined in the project record), each data item in the list of shared data items representing a target task (see [0016]-[0017]; Tasks may be exchanged; also see [0019]; the completion status of each task may be in a project schema, or project record), the list being shared amongst a group comprising a plurality of mobile devices, the group including the mobile device (see Abstract; use IM infrastructures to exchange of tasks or task information; disseminating these projects and tasks among users; also see [0020]; IM application 102 may then share the projects and tasks defined in the project record, with other IM applications. For example, if the project record exported 106 includes the definition of a project which contains five tasks for five different people, IM application 102 may send each task contained in the project record to the appropriate user of a remote IM application; also see [0050]-[0056] in view of Fig.4A:414 and 418; By selecting a group "children" 402, all users 404a and 404b within the group "children" may receive the tasks 410a and 410b), and each data item in the list of shared data items comprising a first indication indicating whether the target task has been assigned to a member of the group (see Fig.3B:332, Fig.3C:346c, Fig.4C:424 and 442 as well as Fig.4D:432) and a second indication indicating whether the target task has been completed (see Fig.3C:346b and Fig.4C:440, 444 and 446; also see [0019]; The data structure or file within which PMA 100 may store information (e.g. the name of the project, the tasks assigned to individuals, the completion status of each task, etc.); also see [0027]; projects and tasks exchanged among users may preferably be self-contained- i.e. in the absence of a central database, all task information, such as task names, completion status, users involved in tasks, etc., may need to be sent from one user to the next);
storing, by the mobile device, the list (see Fig.1-2 in view of [0019]-[0020]; project record imported from a PMA 100 is in XML format and parsed into its discrete project and task components; also see Fig.3D in view of [0044] and [0046] that shows task record is an attachment/ file containing data being stored);
obtaining, by the mobile device, a common message from one of the mobile devices in the group, the common message comprising a new value for updating an existing shared data item in the list or for a new shared data item, the common message having been sent to all mobile devices in the group and indicating to all mobile devices in the group to update a locally stored version of the list (see [0036]; either "scottslip@yahoo.com" or "seanslip@yahoo.com"--is required to mark a task as "complete" for the task to be considered completed, and displayed to all users as completed; also see [0038]; Task metadata section 304 may be updated by users receiving the task record 300, as users add notes to tasks or update the completion status of tasks; also see [0043]; Additional elements and attributes 358 may be added as tasks and projects; also see [0061] in view of Fig.4B-4C; Once any user has completed the task (in the case where the operand "any" 412a had been used); or, all users have completed the task (in the case where the operand "all" 412b had been used) the task may appear "completed" for the "view-only" users 432 and 436; also see [0063]; in response to the designation of a task as complete by the user the IM client 424 may update task-record 419a (FIG. 4B) with the new status of the task. IM 424 may use the manifest portion of the data-record to discern the identifiers of the intended recipients of the task, and send designated recipients an updated task-record);
determining, by the mobile device, whether or not the list comprises the existing shared data item (see [0031]; task record value is a GUID (globally unique identifier) allowing for each task record 300 to be uniquely identified and differentiated from other task records exchanged; also see [0063]-[0064]; IM clients 432 and 436 may receive task-records 441b and 441c, respectively, and process the received task-record and update displayed task and/or project information; also see [0065]-[0066]; The received message may include a new task, for example in a task record; client IMs may discern whether a received task is an update to an existing task or is a new task; This determination may be based on an attribute in the task, such as the RecordID GUID-value in the task manifest);
performing one of following:
adding, by the mobile device, the new value as a new shared data item when the list does not comprise the existing shared data item (see [0065]-[0066]; The received message may include a new task, for example in a task record; also see [0024]; ability to import 208 a project record and data collection, containing project and/or task data, and incorporate 210 the imported data into an existing project; or, create a new project from the imported data; also see [0057]-[0060] in view of new tasks 426a-b and 430a-b added in IM clients for Sydney 424 and Brandon 428 respectively); or
updating, by the mobile device, the list by replacing the existing shared data item with the new value when the list does comprise the existing shared data item (see [0036]; either "scottslip@yahoo.com" or "seanslip@yahoo.com"--is required to mark a task as "complete" for the task to be considered completed, and displayed to all users as completed; also see [0038]; Task metadata section 304 may be updated by users receiving the task record 300, as users add notes to tasks or update the completion status of tasks; also see [0061] in view of Fig.4B-4C; Once any user has completed the task (in the case where the operand "any" 412a had been used); or, all users have completed the task (in the case where the operand "all" 412b had been used) the task may appear "completed" for the "view-only" users 432 and 436; also see [0062]-[0064]; IM clients 432 and 436 may receive task-records 441b and 441c, respectively, and process the received task-record and update displayed task and/or project information; clients 432 and 436 may process its received task 441b-441c and update the proper task 444 and 446 as checked-off; also see [0066]; upon updating the task-record of an existing task, the RecordID may be kept the same, allowing recipient IMs to discern the received task as an update of an existing task);
wherein the portion of the list of shared data items from the mobile device and other portions of the list of shared data item from other mobile devices in the group each comprise data indicating respective recent update information for the shared data items (see [0036]; either "scottslip@yahoo.com" or "seanslip@yahoo.com"--is required to mark a task as "complete" for the task to be considered completed, and displayed to all users as completed; also see [0038]; Task metadata section 304 may be updated by users receiving the task record 300, as users add notes to tasks or update the completion status of tasks; also see [0061] in view of Fig.4B-4C; Once any user has completed the task (in the case where the operand "any" 412a had been used); or, all users have completed the task (in the case where the operand "all" 412b had been used) the task may appear "completed" for the "view-only" users 432 and 436; also see [0062]-[0064]; IM clients 432 and 436 may receive task-records 441b and 441c, respectively, and process the received task-record and update displayed task and/or project information; clients 432 and 436 may process its received task 441b-441c and update the proper task 444 and 446 as checked-off; also see [0066]; upon updating the task-record of an existing task, the RecordID may be kept the same, allowing recipient IMs to discern the received task as an update of an existing task).
Jakobson does not explicitly teach receiving, by the mobile device, a group join request from a new mobile device; sending, by the mobile device, a confirmation to the new mobile device to confirm acceptance of the new mobile device into to the group; and sending, by the mobile device, a portion of the list of shared data items to the new mobile device.
However, in an analogous art, Zourntos discloses receiving, by the mobile device, a group join request from a new mobile device (see [0710]; module to send a join mitigated group (JMG) packet to a nearby matrix node; module sends a request if it wishes to join any of the local groups); and
sending, by the mobile device, a confirmation to the new mobile device to confirm acceptance of the new mobile device into to the group (see [0710]; current members of the mitigated group to give consent to the module's request to join their mitigated group. The default security procedure requires only one user to give consent for a new user to be allowed to enter).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Zourntos with Jakobson to receive, by the mobile device, a group join request from a new mobile device; and to send, by the mobile device, a confirmation to the new mobile device to confirm acceptance of the new mobile device into to the group.
One of ordinary skill in the art would have been motivated so that a new user is allowed to enter a group based on a request to join any of the local groups (Zourntos: see [0710]).
Jakobson (modified by Zourntos) does not explicitly teach sending, by the mobile device, a portion of the list of shared data items to the new mobile device.
However, in an analogous art, Herrero discloses sending, by the mobile device, a portion of the list of shared data items to the new mobile device (see [0009]; the task management system presents a pending task to the new user; also see [0010]; the task management system receives a request from the new user to update the status a pending task. The task management system updates the pending task and later presents the updated task to the same or other users; also see [0038]; Once a user has activated a new account, that user may access tasks associated with the user's e-mail address … including tasks that were created before the new user established the new account).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Herrero with Jakobson and Zourntos to send, by the mobile device, a portion of the list of shared data items to the new mobile device.
One of ordinary skill in the art would have been motivated to encourage cooperative action as between various team members (Herrero: see [0053]).
Regarding claim 2, Jakobson (modified by Zourntos and Herrero) discloses the method according to claim 1, as set forth above. In addition, Jakobson further discloses wherein the common message is obtained from a message exchange service (see [0062]; IM infrastructure 422 may be an instant messaging service provided by a single provider, or may represent multiple instant message providers, allowing users to cross-communicate. Users of IMs exchange text instant messages, files, tasks, etc.).
Regarding claim 3, Jakobson (modified by Zourntos and Herrero) discloses the method according to claim 1, as set forth above. In addition, Jakobson further discloses wherein the shared data items are stored as records in a database as shared data stored individually by each member of the group (see Fig.1-2 in view of [0019]-[0020]; project record imported from a PMA 100 is in XML format and parsed into its discrete project and task components; also see Fig.3D in view of [0044] and [0046] that shows task record is an attachment/ file containing data being stored; also see [0057]-[0060] in view of new tasks 426a-b and 430a-b added in IM clients for Sydney 424 and Brandon 428 respectively).
Regarding claim 4, Jakobson (modified by Zourntos and Herrero) discloses the method according to claim 1, as set forth above. In addition, Jakobson further discloses generating, by the mobile device, an updated list to reflect changes made by other mobile devices in the group (see [0061] in view of Fig.4B-4C; Once any user has completed the task (in the case where the operand "any" 412a had been used); or, all users have completed the task (in the case where the operand "all" 412b had been used) the task may appear "completed" for the "view-only" users 432 and 436; also see [0062]-[0064]; IM clients 432 and 436 may receive task-records 441b and 441c, respectively, and process the received task-record and update displayed task and/or project information; clients 432 and 436 may process its received task 441b-441c and update the proper task 444 and 446 as checked-off; also see [0066]; upon updating the task-record of an existing task, the RecordID may be kept the same, allowing recipient IMs to discern the received task as an update of an existing task).
Regarding claim 5, Jakobson (modified by Zourntos and Herrero) discloses the method according to claim 1, as set forth above. In addition, Jakobson further discloses wherein the new value represents a task in a group project (see [0017]; define projects, containing tasks with complex sets of rules and inter-dependencies, and use IM networks services and/or protocols to disseminate these projects and tasks among users; also see [0065]-[0066]; The received message may include a new task, for example in a task record; also see [0070]; If the user chooses the operand "any", at step 508 the manifest portion of the task-record may be marked as "any". The implication is that the sender of the task requires at least one of the users assigned this task to complete the task (“group project”) for the task to be considered completed), and wherein the task comprises a plurality of values associated therewith indicative of status information for the task (see [0038]; Task metadata section 304 may be updated by users receiving the task record 300, as users add notes to tasks or update the completion status of tasks; also see [0063]; in response to the designation of a task as complete by the user the IM client 424 may update task-record 419a (FIG. 4B) with the new status of the task; also see [0040]; The user may indicate progress they have made on a task, which may be recorded as element attribute "<percent_completed>”).
Regarding claim 6, Jakobson (modified by Zourntos and Herrero) discloses the method according to claim 1, as set forth above. In addition, Jakobson further discloses posting a comment pertaining to a selected one or more of the shared data items (see [0038] and [0040]; users add notes to tasks; Notes pertaining to the task 344 may be recorded as the "<notes>" element attribute).
Regarding claim 7, Jakobson (modified by Zourntos and Herrero) discloses the method according to claim 1, as set forth above. In addition, Jakobson further discloses wherein at least one shared data item in the list has a user assignment to indicate who is responsible for completing that shared data item (see [0050]-[0054] in view of Fig.4A-4C illustrating the assignment of tasks to groups within an IM framework; control 414 may offer the user graphical means of selecting the user, or group, to whom tasks 410a and 410b should be assigned).
Regarding claim 8, Jakobson discloses a method, comprising:
obtaining or generating (Fig.1:108), by a mobile device (Fig.1:102), a list of shared data items (see [0016]; IM application, running on an electronic device, may allow a user to create, assign, track, view, export, import and manage tasks; IM applications may include cellular phone modules; also see [0020]; IM application 102 may import 108 a project record exported from a PMA 100. Once the project record is imported, IM application 102 may share 110 projects and tasks defined in the project record), each data item in the list of shared data items representing a target task (see [0016]-[0017]; Tasks may be exchanged; also see [0019]; the completion status of each task may be in a project schema, or project record), the list being shared amongst a group comprising a plurality of mobile devices, the group including the mobile device (see Abstract; use IM infrastructures to exchange of tasks or task information; disseminating these projects and tasks among users; also see [0020]; IM application 102 may then share the projects and tasks defined in the project record, with other IM applications. For example, if the project record exported 106 includes the definition of a project which contains five tasks for five different people, IM application 102 may send each task contained in the project record to the appropriate user of a remote IM application; also see [0050]-[0056] in view of Fig.4A:414 and 418; By selecting a group "children" 402, all users 404a and 404b within the group "children" may receive the tasks 410a and 410b), and each data item in the list of shared data items comprising a first indication indicating whether the target task has been assigned to a member of the group (see Fig.3B:332, Fig.3C:346c, Fig.4C:424 and 442 as well as Fig.4D:432) and a second indication indicating whether the target task has been completed (see Fig.3C:346b and Fig.4C:440, 444 and 446; also see [0019]; The data structure or file within which PMA 100 may store information (e.g. the name of the project, the tasks assigned to individuals, the completion status of each task, etc.); also see [0027]; projects and tasks exchanged among users may preferably be self-contained- i.e. in the absence of a central database, all task information, such as task names, completion status, users involved in tasks, etc., may need to be sent from one user to the next);
storing, by the mobile device, the list (see Fig.1-2 in view of [0019]-[0020]; project record imported from a PMA 100 is in XML format and parsed into its discrete project and task components; also see Fig.3D in view of [0044] and [0046] that shows task record is an attachment/ file containing data being stored);
generating, by the mobile device, a common message (see Fig.2:204; also see [0067]; IM client to generate and disseminate updated task-records to all recipients in the task manifest), the common message comprising a new value for updating an existing shared data item in the list or for a new shared data item, and the common message indicating to all mobile devices in the group to update a locally stored version of the list (see [0036]; either "scottslip@yahoo.com" or "seanslip@yahoo.com"--is required to mark a task as "complete" for the task to be considered completed, and displayed to all users as completed; also see [0038]; Task metadata section 304 may be updated by users receiving the task record 300, as users add notes to tasks or update the completion status of tasks; also see [0043]; Additional elements and attributes 358 may be added as tasks and projects; also see [0061] in view of Fig.4B-4C; Once any user has completed the task (in the case where the operand "any" 412a had been used); or, all users have completed the task (in the case where the operand "all" 412b had been used) the task may appear "completed" for the "view-only" users 432 and 436; also see [0063]; in response to the designation of a task as complete by the user the IM client 424 may update task-record 419a (FIG. 4B) with the new status of the task. IM 424 may use the manifest portion of the data-record to discern the identifiers of the intended recipients of the task, and send designated recipients an updated task-record); and
sending, by the mobile device, the common message to other mobile devices in the group (see Fig.2:204; also see [0067]; IM client to generate and disseminate updated task-records to all recipients in the task manifest) the common message indicating to the other mobile devices to add the new value as a new shared data item when the list does not comprise the existing shared data item (see [0065]-[0066]; The received message may include a new task, for example in a task record; also see [0024]; ability to import 208 a project record and data collection, containing project and/or task data, and incorporate 210 the imported data into an existing project; or, create a new project from the imported data; also see [0057]-[0060] in view of new tasks 426a-b and 430a-b added in IM clients for Sydney 424 and Brandon 428 respectively) or update the list by replacing the existing shared data item with the new value when the list does comprise the existing shared data item (see [0036]; either "scottslip@yahoo.com" or "seanslip@yahoo.com"--is required to mark a task as "complete" for the task to be considered completed, and displayed to all users as completed; also see [0038]; Task metadata section 304 may be updated by users receiving the task record 300, as users add notes to tasks or update the completion status of tasks; also see [0061] in view of Fig.4B-4C; Once any user has completed the task (in the case where the operand "any" 412a had been used); or, all users have completed the task (in the case where the operand "all" 412b had been used) the task may appear "completed" for the "view-only" users 432 and 436; also see [0062]-[0064]; IM clients 432 and 436 may receive task-records 441b and 441c, respectively, and process the received task-record and update displayed task and/or project information; clients 432 and 436 may process its received task 441b-441c and update the proper task 444 and 446 as checked-off; also see [0066]; upon updating the task-record of an existing task, the RecordID may be kept the same, allowing recipient IMs to discern the received task as an update of an existing task);
wherein the portion of the list of shared data items from the mobile device and other portions of the list of shared data item from other mobile devices in the group each comprise data indicating respective recent update information for the shared data items (see [0036]; either "scottslip@yahoo.com" or "seanslip@yahoo.com"--is required to mark a task as "complete" for the task to be considered completed, and displayed to all users as completed; also see [0038]; Task metadata section 304 may be updated by users receiving the task record 300, as users add notes to tasks or update the completion status of tasks; also see [0061] in view of Fig.4B-4C; Once any user has completed the task (in the case where the operand "any" 412a had been used); or, all users have completed the task (in the case where the operand "all" 412b had been used) the task may appear "completed" for the "view-only" users 432 and 436; also see [0062]-[0064]; IM clients 432 and 436 may receive task-records 441b and 441c, respectively, and process the received task-record and update displayed task and/or project information; clients 432 and 436 may process its received task 441b-441c and update the proper task 444 and 446 as checked-off; also see [0066]; upon updating the task-record of an existing task, the RecordID may be kept the same, allowing recipient IMs to discern the received task as an update of an existing task).
Jakobson does not explicitly teach receiving, by the mobile device, a group join request from a new mobile device; sending, by the mobile device, a confirmation to the new mobile device to confirm acceptance of the new mobile device into to the group; and sending, by the mobile device, a portion of the list of shared data items to the new mobile device.
However, in an analogous art, Zourntos discloses receiving, by the mobile device, a group join request from a new mobile device (see [0710]; module to send a join mitigated group (JMG) packet to a nearby matrix node; module sends a request if it wishes to join any of the local groups); and
sending, by the mobile device, a confirmation to the new mobile device to confirm acceptance of the new mobile device into to the group (see [0710]; current members of the mitigated group to give consent to the module's request to join their mitigated group. The default security procedure requires only one user to give consent for a new user to be allowed to enter).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Zourntos with Jakobson to receive, by the mobile device, a group join request from a new mobile device; and to send, by the mobile device, a confirmation to the new mobile device to confirm acceptance of the new mobile device into to the group.
One of ordinary skill in the art would have been motivated so that a new user is allowed to enter a group based on a request to join any of the local groups (Zourntos: see [0710]).
Jakobson (modified by Zourntos) does not explicitly teach sending, by the mobile device, a portion of the list of shared data items to the new mobile device.
However, in an analogous art, Herrero discloses sending, by the mobile device, a portion of the list of shared data items to the new mobile device (see [0009]; the task management system presents a pending task to the new user; also see [0010]; the task management system receives a request from the new user to update the status a pending task. The task management system updates the pending task and later presents the updated task to the same or other users; also see [0038]; Once a user has activated a new account, that user may access tasks associated with the user's e-mail address … including tasks that were created before the new user established the new account).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Herrero with Jakobson and Zourntos to send, by the mobile device, a portion of the list of shared data items to the new mobile device.
One of ordinary skill in the art would have been motivated to encourage cooperative action as between various team members (Herrero: see [0053]).
Regarding claim 9, Jakobson (modified by Zourntos and Herrero) discloses the method according to claim 8, as set forth above. In addition, Jakobson further discloses wherein the common message is sent via a message exchange service (see [0062]; IM infrastructure 422 may be an instant messaging service provided by a single provider, or may represent multiple instant message providers, allowing users to cross-communicate. Users of IMs exchange text instant messages, files, tasks, etc.).
Regarding claim 10, Jakobson (modified by Zourntos and Herrero) discloses the method according to claim 8, as set forth above. In addition, Jakobson further discloses:
generating, by the mobile device, a list of shared data items (see Fig.2:204; also see [0067]; IM client to generate and disseminate updated task-records to all recipients in the task manifest), each data item in the list of shared data items representing a target task (see [0016]-[0017]; IM application, running on an electronic device, may allow a user to create, assign, track, view, export, import and manage tasks; IM applications may include cellular phone modules; Once the project record is imported, IM application 102 may share 110 projects and tasks defined in the project record; Tasks may be exchanged; also see [0019]; the completion status of each task may be in a project schema, or project record), the list being shared amongst a group comprising a plurality of mobile devices, the group including the mobile device (see Abstract; use IM infrastructures to exchange of tasks or task information; disseminating these projects and tasks among users; also see [0020]; IM application 102 may then share the projects and tasks defined in the project record, with other IM applications. For example, if the project record exported 106 includes the definition of a project which contains five tasks for five different people, IM application 102 may send each task contained in the project record to the appropriate user of a remote IM application; also see [0050]-[0056] in view of Fig.4A:414 and 418; By selecting a group "children" 402, all users 404a and 404b within the group "children" may receive the tasks 410a and 410b);
sharing, by the mobile device, the list with the other mobile devices in the group (see Fig.2:204; also see [0067]; IM client to generate and disseminate updated task-records to all recipients in the task manifest).
Regarding claim 11, Jakobson (modified by Zourntos and Herrero) discloses the method according to claim 10, as set forth above. In addition, Jakobson further discloses wherein the sharing comprises sending the list via a message exchange service (see [0062]; IM infrastructure 422 may be an instant messaging service provided by a single provider, or may represent multiple instant message providers, allowing users to cross-communicate. Users of IMs exchange text instant messages, files, tasks, etc.).
Regarding claim 12, Jakobson (modified by Zourntos and Herrero) discloses the method according to claim 10, as set forth above. In addition, Jakobson further discloses wherein the list is shared amongst only a subset of the group of mobile devices (see [0050]-[0055]; allow the creation of group names and the grouping of contacts into groups; control 414 may offer the user graphical means of selecting the user, or group, to whom tasks 410a and 410b should be assigned; A "send" command may cause all properties: tasks 410a and 410b, users/groups assigned-to 414, users/groups for view-only 416, "any/all" operand 412a /412b, etc.--to be aggregated into a task record 419 for transmission to communication network 420).
As for Claim(s) 13, the claims list all the same elements of claim 1, but in a mobile device (see [0085] in view of Fig.7:704; also see [0016]-[0017]; IM application, running on an electronic device, may allow a user to create, assign, track, view, export, import and manage tasks; IM applications may include cellular phone modules) comprising: at least one processor; and one or more memories coupled to the at least one processor and storing programming instructions for execution by the at least one processor (processor(s) and memory are inherent components in mobile electronic device 704, such as a cellular phone) to carry out the steps of claim 1, rather than the method form. Therefore, the supporting rationale of the rejection to claim 1 applies equally as well to claim 13.
As for Claim 14-19, the claims depend on claim 13, but do not teach or further define over the limitations in claims 2-7 respectively. Therefore, claims 14-19 are rejected for the same reasons as set forth in claims 2-7 respectively.
As for Claim 20, the claim depends on claim 13, but does not teach or further define over the limitations in claim 10. Therefore, claim 20 is rejected for the same reasons as set forth in claim 10.
Additional References
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
BLANCHETTE (WO 9004819 A1) discloses a system for cooperatively reassigning duties in a multiple controller environment.
Nguyen et al. (US 20050273403 A1) teaches a new device submits a request to join group over the network, and upon acceptance of the new device , the department codes are sent to the new device by at least one of the devices already belonging to the group.
Posner et al. (US 20060079244 A1) discloses system and method for collecting continuous location updates while minimizing overall network utilization.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SANDARVA KHANAL whose telephone number is (571)272-8107. The examiner can normally be reached MON-FRI, 0800-1700.
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, Kamal B Divecha can be reached at 571-272-5863. 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.
/SANDARVA KHANAL/Primary Examiner, Art Unit 2453