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 . In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
DETAILED ACTION
The following NON-FINAL Office Action is in response to Application 18953128 - filed on 11/20/2024.
Priority
Receipt is acknowledged of papers submitted under 35 U.S.C. 119(a)-(d), which papers have been placed of record in the file.
The Examiner has noted the Applicant claiming Priority from Provisional Application 63/557,629 filed 2/26/2024.
Status of Claims
Claims 1-21 are currently pending of which:
Claims 1-21 are currently under examination and have been rejected as follows.
IDS
The information disclosure statement filed on 9/20/2025 complies with the provisions of 37 CFR 1.97, 1.98 and MPEP § 609 and is considered by the Examiner.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked. As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function. Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function. Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitations use a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier.
In this instant case:
Claim 1 is a “device” claim which recites:
an assignment database, configured to store a plurality of past maintenance records
an assignment filtering module, configured to be communicatively connected to the assignment database to receive a maintenance case in a task list
a code generation module, configured to generate a group code
a team management module, configured to be communicatively connected to the code generation module and receive a selection command for a designated team leader chosen from the candidate team leader list.
Examiner interprets “assignment database”, “assignment filtering module”, “code generation module”, and “team management module” as generic placeholders followed by their respective functions of: “store”, “receive”, “generate”, and “receive”, and further not modified by sufficient structure. Thus, it appears that independent claim 1 invokes 35 USC 112(f).
Because these claim limitations are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, they are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof. If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-21 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claims 1-10 are directed to a device or machine which is a statutory category.
Claims 11-21 are directed to a method or process which is a statutory category.
Step 2A Prong One: The claims recite, describe, or set forth a judicial exception of an abstract idea (see MPEP 2106.04(a)). Specifically, the claims recite, describe or set forth business relations, managing personal behavior or relationships or interactions between people, and concepts performed in the human mind (observation, evaluation, and judgement) including: “receive a maintenance case in a task list”, “search the past maintenance records in the assignment database to obtain a candidate team leader list”, “generate a group code”, “receive a selection command for a designated team leader chosen”, “generate the group code based on a team leader identity… in response to verifying that the selection… for the designated team leader matches the team leader identity”, “the group code is displayed… allowing the group code to be scanned by… a plurality of team members to form a task team”. Receiving maintenance tasks, searching maintenance records to identify appropriate technician leaders, generating group codes for additional technicians based on the leaders, and communicating the information to technicians to form a task team fall within business relations as it pertains to commercial or legal interactions and managing personal behavior or relationships or interactions between people, each under the larger abstract grouping Certain Methods of Organizing Human Activity (MPEP 2106.04(a)(2) II); as well as falling within observation, evaluation, and judgement as they pertain to concepts performed in the human mind under the abstract grouping Mental Processes1 (MPEP 2106.04(a)(2) III).
Step 2A Prong Two: Independent claims 1, 11 recite the following additional elements: “maintenance task assignment device”, “assignment database”, “assignment filtering module”, “code generation module”, “team management module”, “first user device”, and “second user device”. The functions of these additional elements include examples such as “store a plurality of past maintenance records”, “receive a maintenance case in a task list, and search the past maintenance records in the assignment database to obtain a candidate team leader list based on the past maintenance records”, “receive a selection command for a designated team leader chosen from the candidate team leader list”, “generate the group code based on a team leader identity data entry in response to verifying that the selection command for the designated team leader matches the team leader identity data entry sent from a first user device of the designated team leader”, and “the group code is displayed on the first user device of the designated team leader, allowing the group code to be scanned by a plurality of second user devices of a plurality of team members to form a task team”. The additional elements are recited at a high level of generality (i.e. as a generic computer performing functions of receiving, searching for, generating, communicating, and presenting data, etc.) such that they amount to no more than mere instructions to apply the exception using generic computer components. Therefore, these functions can be viewed as not meaningfully different than a business method or mathematical algorithm being applied on a general-purpose computer as tested per MPEP 2106.05(f)(2)(i). The claims are directed to an abstract idea and the judicial exception does not integrate the abstract idea into a practical application.
Step 2B: According to MPEP 2106.05(f)(1), considering whether the claim recites only the idea of a solution or outcome i.e., the claims fail to recite the technological details of how the actual technological solution to the actual technological problem is accomplished. The recitation of claim limitations that attempt to cover an entrepreneurial and thus abstract solution to an entrepreneurial problem with no technological details on how the technological result is accomplished and no description of the mechanism for accomplishing the result do not provide significantly more than the judicial exception.
Dependent claims 5, 15 recite the additional element “external terminal”. The function of this additional computer-based is to receive selection of a chosen team leader. The functions of these additional elements include examples such as “run parallelized statistical analysis” and “prompt the respondent to select”. The additional element is also recited at a high level of generality (i.e. as a generic computer performing functions of communicating and presenting data, etc.) such that they amount to no more than mere instructions to apply the exception using generic computer components.
Further, dependent claims 2-4, 6-10, 12-14, 16-21 merely incorporate the additional elements recited in claims 1, 11 along with further narrowing of the abstract idea of claims 1, 11 and their execution of the abstract idea. Specifically, the dependent claims narrow the “maintenance task assignment device”, “assignment database”, “assignment filtering module”, “code generation module”, “team management module”, “first user device”, and “second user device” to capabilities such as receive, scan, set, generate, encrypt, transmit, obtain, send, store, include, and confirm various forms of data such as scan information, identity data, group codes, team members, team leaders, group information, encryption keys, team leaders lists, task lists, update status, team duration time, filtering criteria, average times, attendance days, numbers of cases, etc. which, when evaluated per MPEP 2106.05(f)(2) represent mere invocation of computers to perform existing processes. Therefore, the additional elements recited in the claimed invention individually and in combination fail to integrate a judicial exception into a practical application (Step 2A prong two) and for the same reasons they also fail to provide significantly more (Step 2B). Thus, claims 1-21 are reasoned to be patent ineligible.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
REJECTIONS BASED ON PRIOR ART
Examiner Note: Some rejections will contain bracketed comments preceded by an “EN” that will denote an examiner note. This will be placed to further explain a rejection.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 of this title, 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.
Claims 1-21 are rejected under 35 U.S.C. 103 as being unpatentable over:
Lewis et al. US 20140333412 A1, hereinafter Lewis in view of
Zhang et al. US 20200372439 A1, hereinafter Zhang, and in further view of
Daly US 20210326410 A1, hereinafter Daly. As per,
Regarding claims 1, 11: Lewis teaches:
A maintenance task assignment device (claim 1) / method (claim 11) (Lewis ¶ [0010]: The present invention relates to methods, systems, and/or devices which utilize a virtual badge system for use in various stages of operations, including emergency or emergent circumstances. ¶ [0138]: The Team List also allows users to be tasked for functional purposes, by allowing users to be assigned to Tasks, Needs, Work Orders, Events, Affiliations, and potentially other uses. ¶ [0235]: the virtual badge may contain similar information to a person’s identification data such as… maintenance required (like servicing a generator)), comprising:
[..]
an assignment filtering module, configured to be communicatively connected to the assignment database to receive a maintenance case in a task list (claim 1) / receiving, by an assignment filtering module, a task list including a maintenance case (claim 11) (Lewis mid-¶ [0034]: Using a virtual badge, the worker can be monitored and/or tracked via GPS technologies to verify performance of his/her duties [EN: maintenance case]… Using the virtual badge forms, the [worker] could use a checklist [EN: task list] or drop down menu of various services provided, including taking any photos as needed, all of which data is time/date stamped and geocoded by the system to validate the services actually were provided. Mid-¶ [0138]: The Team List also allows users to be tasked for functional purposes, by allowing users to be assigned to Tasks, Needs, Work Orders [EN: maintenance cases], Events, Affiliations, and potentially other uses), and
[..]
a code generation module, configured to generate a group code (Lewis end-¶ [0143]: Users can be assigned “Friend Codes,” which are unique identifiers that allow for user search to take place and for user created sub-groups); and
[..]
the group code is displayed on the first user device of the designated team leader, allowing the group code to be scanned by a plurality of second user devices of a plurality of team members to form a task team (Lewis end-¶ [0143]: Users can be assigned “Friend Codes,” which are unique identifiers that allow for user search to take place and for user created sub-groups. Mid-¶ [0159]: “Badge” allows the user [EN: team leader] to view their virtual badge screen in the application, which can display their name, employer, photo, address, phone number, issuing agency, credentials, encrypted QR code, and/or additional other information ¶ [0160]: ‘Scanner’ allows the administrator to activate a QR code scanner in the virtual badge application on the mobile electronic display device, which enables the scanner user to ‘scan’ another virtual badge user's encrypted QR code on their virtual badge. ¶ [0161]: ‘Check-In List’ allows the administrator to view the list of scanned-in and checked-in users to pre-defined areas, for easy identification that there may or may not be users that are still scanned-in. As another option within the system, a supervisor may view his team of virtual badge users on his mobile electronic device with the software on this list).
Although Lewis teaches a maintenance task assignment device receiving cases and task lists, generating group codes, and team members scanning codes displayed on the team leader device, Lewis does not specifically teach searching a database of past work records to obtain a candidate team leader list, receiving a selection for team leader, or where the group code is based on verification of team leader ID data.
However, Zhang in analogous art of group collaboration IoT systems teaches or suggests:
an assignment database, configured to store a plurality of past [..] records (Zhang ¶ [0174]: In 810, the processing device 112 may obtain the historical team determination data [EN: past records] relating to the plurality of team leaders and the plurality of team members. In some embodiments, step 810 may be performed by the information obtaining module 410 [EN: assignment database]. ¶ [0237]: In 1210, the processing device 112 (e.g., the information obtaining module 410) may obtain historical order information relating to each of the plurality of team participants to be grouped. The historical order information may include information of drivers, order accepting time, or order accepting location… The historical order information may also include all the information contained in the historical order, as well as other required information);
[..]
search (claim 1) / searching, by the assignment filtering module (claim 11), the past [..] records in the assignment database to obtain a candidate team leader list based on the past [..] records (Zhang ¶ [0125]: In 510, the processing device 112 (e.g., the information obtaining [EN: search] module 410) may obtain information [EN: search records] relating to each of a plurality of team participants (e.g., the service providers) to be grouped. The plurality of team participants may include a plurality of team leaders and a plurality of team members);
[..]
a team management module, configured to be communicatively connected to the code generation module and receive (claim 1) / receiving, by a team management module (claim 11), a selection command for a designated team leader chosen from the candidate team leader list (Zhang end-¶ [0171]: In some embodiments, a two-way selection mechanism can also be employed. For example, the system 100 may recommend multiple team members to each team leader, and recommend one or more team leaders to each team member. Only when a team leader selects a team member and the team member also selects the team leader, the team member can join the team leader's team).
Zhang and Lewis are found as analogous art of group collaboration IoT systems. It would have been obvious to one skilled in the art, before the effective filing date of the invention, to have modified Lewis’ virtual badge device and method to have included Zhang’s teachings around searching a database of past work records to obtain a candidate team leader list and receiving a selection for team leader. The benefit of these additional features would have facilitated and encouraged teamwork among team members (Zhang ¶ [0005]). The predictability of such modifications and/or variations, would have been corroborated by the broad level of skill of one of ordinary skills in the art as articulated by Lewis in view of Zhang (see MPEP 2143 G).
Further, the claimed invention could have also been viewed as a mere combination of old elements in a similar field of group collaboration IoT systems. In such combination each element would have merely performed the same function as it did separately. Thus, one of ordinary skill in the art would have recognized that, given existing technical ability to combine the elements, as evidenced by Lewis in view of Zhang above, the to- be combined elements would have fit together like pieces of a puzzle in a logical, complementary, technologically feasible and/or economically desirable manner. Thus, it would have been reasoned that the results of the combination would have been predictable (see MPEP 2143 A).
Furthermore, Daly in analogous art of group collaboration IoT systems teaches or suggests:
wherein the team management module instructs the code generation module to generate the group code based on a team leader identity data entry in response to verifying that the selection command for the designated team leader matches the team leader identity data entry sent from a first user device of the designated team leader (See Daly Fig. 11 showing group leader, group, invited users, Unique Group PIN, user identifies; and related text. Mid-¶ [0173]: Referring now to FIGS. 8A-C, FIG. 9 and FIG. 10, there are illustrated sequence diagrams for initiating a user registration sequence in order to register a normal user and also define a group leader… At the application, the user device 102 then sends identity information for registration begins verification at the server 106. This identity information is a user's information for dedication and verification purposes. The system then enters a loop 806 in order to verify the phone number via an SMS message, where a code that is generated by the server 106 is sent to the user device 102. Mid-¶ [0174]: …a code generated by the server 106 is sent to the user via some method, such as email, and, once the user inputs the code in the email verification step, the email address is verified. This is facilitated in a loop 810 wherein the user inputs the email code to the application 804, which then forwards this code to the server 106. ¶ [0175]: …once the user has verified their contact information, to fill out the rest of the information gathered by the system: country, gender, date of birth. The user will be required to provide a password to authenticate with the system. In this process, communication to the server is encrypted with the SMS code, thereby allowing both the system and the user to be able to derive the same a key to be able to transmit the user's personal information in a secure manner).
Daly, Zhang and Lewis are found as analogous art of group collaboration IoT systems. It would have been obvious to one skilled in the art, before the effective filing date of the invention, to have modified Lewis / Zhang’s virtual badge participant orgnanization system and method to have included Daly’s teachings around basing a group code on verification of team leader ID data. The benefit of these additional features would have improved the security of confidential communication group channels (Daly ¶ [0005]). The predictability of such modifications and/or variations, would have been corroborated by the broad level of skill of one of ordinary skills in the art as articulated by Lewis in view of Zhang and Daly (see MPEP 2143 G).
Further, the claimed invention could have also been viewed as a mere combination of old elements in a similar field of group collaboration IoT systems. In such combination each element would have merely performed the same function as it did separately. Thus, one of ordinary skill in the art would have recognized that, given existing technical ability to combine the elements, as evidenced by Lewis in view of Zhang and Daly above, the to- be combined elements would have fit together like pieces of a puzzle in a logical, complementary, technologically feasible and/or economically desirable manner. Thus, it would have been reasoned that the results of the combination would have been predictable (see MPEP 2143 A).
Regarding claims 2, 12: Lewis / Zhang / Daly teaches all the limitations of claim 1, 11 above.
Lewis further teaches:
wherein the team management module receives (claim 2) / receiving, by the team management module (claim 12), corresponding scan information items generated by the second user devices of the team members after the second user devices scan the group code, and the team management module receives identity data entries of the team members sent from the second user devices of the team members (Lewis end-¶ [0143]: Users can be assigned “Friend Codes,” which are unique identifiers that allow for user search to take place and for user created sub-groups. ¶ [0160]: ‘Scanner’ allows the administrator to activate a QR code scanner in the virtual badge application on the mobile electronic display device, which enables the scanner user to ‘scan’ another virtual badge user's encrypted QR code on their virtual badge. ¶ [0161]: ‘Check-In List’ allows the administrator to view the list of scanned-in and checked-in users to pre-defined areas, for easy identification that there may or may not be users that are still scanned-in. As another option within the system, a supervisor may view his team of virtual badge users on his mobile electronic device with the software on this list. ¶ [0256]: Referring to FIG. 21, an illustrative embodiment of the virtual badge 502 as illustrated in FIG. 20 is shown. The virtual badge in the phone, or a handset, can be designed and programmed to be functional by displaying fixed data or data that can be changed, include a variety of information such as an image 514, a picture of the individual, a barcode or QR code 516 (provides for additional functionality) which contains the same and/or additional data about the user and which can be scanned for that data on the image via another electronic device with scanning technology or any other scanning technology, such as barcode or QR code readers. This virtual badge concept in this figure can be applied to electronic devices like both Smartphones and Feature phones alike);
wherein based on the team leader identity data entry, the identity data entries of the team members, and the scan information items, the team management module sets (claim 2) / setting, by the team management module (claim 12), the first user device of the designated team leader and the second user devices of the team members as the task team (Lewis ¶ [0138]: ‘Team List’ allows users to easily create groups, teams, and task forces to organize and manage their users. Such teams also allow for a virtual badge leader to form a team of other virtual badge holders who may not have electronic devices with the software system on them [EN: however, the user devices are still linked to the task team – see ¶s [0160-0161]]. The Team List also allows users to be tasked for functional purposes, by allowing users to be assigned to Tasks, Needs, Work Orders, Events, Affiliations, and potentially other uses).
Regarding claims 3, 13: Lewis / Zhang / Daly teaches all the limitations of claims 1, 11 above.
Although Lewis teaches generating group codes and team members scanning codes displayed on the team leader device, Lewis does not specifically teach basing the group code on verification of team leader ID data nor encrypting the group information with an encryption key.
However, Daly in analogous art of group collaboration IoT systems teaches or suggests:
wherein the team management module generates (claim 3) / generating, by the team management module (claim 13), a group information entry and an encryption key based on the team leader identity data entry, and encrypts (claim 3) / encrypting, by the team management module (claim 13), the group information entry by using the encryption key to generate an encrypted group information entry, the code generation module subsequently generates (claim 3) / generating, by the code generation module (claim 13), the group code according to the encrypted group information entry (See Daly Fig. 11 showing group leader, group, invited users, Unique Group PIN, user identifies; and related text. ¶ [0180]: Referring now to FIG. 12 and FIG. 13, there is illustrated the process for bonding with the IoT device 104, the sequence illustrating that the IoT device 104 must be registered with the group leader before being able to use it securely…. This device shared encryption key will be registered in the IoT device 104 through the system application's connection to the IoT device 104, but not on the actual application 804 itself. This is illustrated as the path (7) which path illustrates the shared key being passed to the application 804 and then the group key plus the group leader hash plus the shared key plus the user's hash, if available, is then relayed to the chip 1302 in the device 104. This is a registration process of the shared encryption key with the device 104. Paths (8) and (9) illustrate the transmission of the group leader hash+shared key and the user's hash, respectively. This operation comprises the registration of the group key into the IoT device 104 (and not in the application 804), this being the created group private key from the group user PIN/image dataset).
Daly, Zhang and Lewis are found as analogous art of group collaboration IoT systems. It would have been obvious to one skilled in the art, before the effective filing date of the invention, to have modified Lewis / Zhang’s virtual badge participant orgnanization system and method to have included Daly’s teachings around basing the group code on verification of team leader ID data and encrypting the group information with an encryption key. The benefit of these additional features would have improved the security of confidential communication group channels (Daly ¶ [0005]). The predictability of such modifications and/or variations, would have been corroborated by the broad level of skill of one of ordinary skills in the art as articulated by Lewis in view of Zhang and Daly (see MPEP 2143 G).
Further, the claimed invention could have also been viewed as a mere combination of old elements in a similar field of group collaboration IoT systems. In such combination each element would have merely performed the same function as it did separately. Thus, one of ordinary skill in the art would have recognized that, given existing technical ability to combine the elements, as evidenced by Lewis in view of Zhang and Daly above, the to- be combined elements would have fit together like pieces of a puzzle in a logical, complementary, technologically feasible and/or economically desirable manner. Thus, it would have been reasoned that the results of the combination would have been predictable (see MPEP 2143 A).
Regarding claims 4, 14: Lewis / Zhang / Daly teaches all the limitations of claims 3, 13 above.
Although Lewis teaches generating group codes and team members scanning codes displayed on the team leader device, Lewis does not specifically teach transmitting encrypted group information and encryption keys for decryption.
However, Daly in analogous art of group collaboration IoT systems teaches or suggests:
wherein the code generation module transmits (claim 4) / transmitting, by the code generation module (claim 14), the group code including the encrypted group information entry to the first user device of the designated team leader, and the team management module transmits (claim 4) / transmitting, by the team management module (claim 14), the encryption key to the second user devices of the team members (Daly mid-¶ [0180]: This is illustrated as the path (7) which path illustrates the shared key being passed to the application 804 and then the group key plus the group leader hash plus the shared key plus the user's hash, if available, is then relayed to the chip 1302 in the device 104. This is a registration process of the shared encryption key with the device 104. Paths (8) and (9) illustrate the transmission of the group leader hash+shared key and the user's hash, respectively. This operation comprises the registration of the group key into the IoT device 104 (and not in the application 804), this being the created group private key from the group user PIN/image dataset), and
wherein the scan information item is the group information entry obtained by decrypting the encrypted group information entry by using the encryption key (See Daly Fig. 16A and related text: Device is online -> Respond with connection acknowledgement -> Encrypt connection acknowledgement with group encryption key -> Decrypt and process connection acknowledgement -> Peer to peer connection established).
Daly, Zhang and Lewis are found as analogous art of group collaboration IoT systems. It would have been obvious to one skilled in the art, before the effective filing date of the invention, to have modified Lewis / Zhang’s virtual badge participant orgnanization system and method to have included Daly’s teachings around transmitting encrypted group information and encryption keys for decryption. The benefit of these additional features would have improved the security of confidential communication group channels (Daly ¶ [0005]). The predictability of such modifications and/or variations, would have been corroborated by the broad level of skill of one of ordinary skills in the art as articulated by Lewis in view of Zhang and Daly (see MPEP 2143 G).
Further, the claimed invention could have also been viewed as a mere combination of old elements in a similar field of group collaboration IoT systems. In such combination each element would have merely performed the same function as it did separately. Thus, one of ordinary skill in the art would have recognized that, given existing technical ability to combine the elements, as evidenced by Lewis in view of Zhang and Daly above, the to- be combined elements would have fit together like pieces of a puzzle in a logical, complementary, technologically feasible and/or economically desirable manner. Thus, it would have been reasoned that the results of the combination would have been predictable (see MPEP 2143 A).
Regarding claims 5, 15: Lewis / Zhang / Daly teaches all the limitations of claims 4, 14 above.
Although Lewis teaches team members scanning codes displayed on the team leader device, Lewis does not specifically teach receiving from an external terminal a selection for team leader from a candidate team leader list.
However, Zhang in analogous art of group collaboration IoT systems teaches or suggests:
wherein the assignment filtering module further provides (claim 5) / providing, by the assignment filtering module (claim 15), the candidate team leader list to an external terminal for selection, and the team management module receives the selection command for the designated team leader chosen from the candidate team leader list from the external terminal (Zhang end-¶ [0171]: In some embodiments, a two-way selection mechanism can also be employed. For example, the system 100 may recommend multiple team members to each team leader, and recommend one or more team leaders to each team member. Only when a team leader selects a team member and the team member also selects the team leader, the team member can join the team leader's team. ¶ [0115]: The communication component 308 may be configured to facilitate wired or wireless communication between the user terminal 300-2 and other devices. The user terminal 300-2 can access a wireless network based on a communication standard such as Wi-Fi, 2G or 3G, or a combination thereof. In some embodiments, the communication component 308 may receive broadcast signals or broadcast related information from an external broadcast management system via a broadcast channel).
Rationales to have modified / combined Lewis / Zhang / Daly are above regarding claim 1 and reincorporated.
Regarding claims 6, 16: Lewis / Zhang / Daly teaches all the limitations of claims 1, 11 above.
Lewis further teaches:
wherein the team management module sends (claim 6) / sending, by the team management module (claim 16), the task list to the first user device of the designated team leader in the task team and the second user devices of the team members in the task team (Lewis ¶ [0138]: …Such teams also allow for a virtual badge leader to form a team of other virtual badge holders… The Team List also allows users to be tasked for functional purposes, by allowing users to be assigned to Tasks, Needs, Work Orders, Events, Affiliations, and potentially other uses. Users may be organized and assigned to tasks via a ‘Drag and Drop' interface).
Regarding claims 7, 17: Lewis / Zhang / Daly teaches all the limitations of claims 6, 16 above.
Lewis further teaches:
wherein the assignment database stores (claim 7) / storing, by the assignment database (claim 17), an updated task list based on an update status of the task list inputted from the first user device of the designated team leader in the task team and the second user devices of the team members in the task team (Lewis ¶ [0144]: "Notifications: allow users to view at-a-glance any status updates or pertinent information from selected users or an administrator, and functions as a rudimentary news feed to the user, displaying updated information about the user's affiliations, coworkers, friends, and family. The Notifications list also displays PUSH notifications sent by the administrator to virtual badge users as a group or individually. Mid-¶ [0245]: This updates the system to sort and ‘Type’ the individuals or volunteers, as well as to assist with assigning appropriate tasks to appropriately qualified virtual badge users. ¶ [0138]: …Such teams also allow for a virtual badge leader to form a team of other virtual badge holders… The Team List also allows users to be tasked for functional purposes, by allowing users to be assigned to Tasks, Needs, Work Orders, Events, Affiliations, and potentially other uses. Users may be organized and assigned to tasks via a ‘Drag and Drop' interface).
Regarding claims 8, 18: Lewis / Zhang / Daly teaches all the limitations of claims 7, 17 above.
Lewis further teaches:
wherein the team management module sets (claim 8) / setting, by the team management module (claim 18), a team duration time for the task team, the team duration time has an upper limit value or is set based on the update status of the task list (Lewis mid-¶ [0235]: …the virtual badge may contain similar information to a person’s identification data such as a photo, data, location, quantity, condition, clock in, clock out, timed maintenance [EN: with upper time limit] required (like servicing a generator)).
Regarding claims 9, 19: Lewis / Zhang / Daly teaches all the limitations of claims 1, 11 above.
Although Lewis teaches team members scanning codes displayed on the team leader device, Lewis does not specifically teach receiving a selection for team leader from a candidate team leader list filtered by cases handled, average maintenance time, or attendance.
However, Zhang in analogous art of group collaboration IoT systems teaches or suggests:
wherein the assignment filtering module obtains a team leader list based on the past maintenance records, (claim 9) / obtaining, by the assignment filtering module, a team leader list based on the past maintenance records (claim 19); and further obtains (claim 9) / obtaining, by the assignment filtering module (claim 19), the candidate team leader list from the team leaders in the team leader list according to a filtering criterion based on the past maintenance records, and wherein the filtering criterion includes at least one of a number of cases handled in an area by the team leaders, average maintenance time, attendance days of a current month, and a number of cases undertaken on a current day (Zhang ¶ [0148]: In some embodiments, the system 100 may require a requestor requesting forming a team (registering as a team leader and/or team member) after satisfying certain conditions [EN: filtering criteria]. In some embodiments, the condition may include, but is not limited to, the service time… exceeds a certain threshold (e.g., half year, 1 year, 2 years, 3 years, etc.), the number (or count) of completed service orders exceeds a certain threshold (e.g. 500 orders, 1000 orders, etc.), service evaluation… exceeds certain threshold (e.g., scores greater than 4.5/5 points), or the like… the criteria for registering as a team leader may be higher than the criteria for registering as a team member… the number (or count) of times that he/she has been a team member for the team formation exceeds a certain threshold (e.g., 10, 20, etc.)).
Zhang and Lewis (and Daly) are found as analogous art of group collaboration IoT systems. It would have been obvious to one skilled in the art, before the effective filing date of the invention, to have modified Lewis’ virtual badge device and method to have included Zhang’s teachings around receiving a selection for team leader from a candidate team leader list filtered by history of cases handled. The benefit of these additional features would have facilitated and encouraged teamwork among team members (Zhang ¶ [0005]). The predictability of such modifications and/or variations, would have been corroborated by the broad level of skill of one of ordinary skills in the art as articulated by Lewis in view of Zhang and Daly (see MPEP 2143 G).
Further, the claimed invention could have also been viewed as a mere combination of old elements in a similar field of group collaboration IoT systems. In such combination each element would have merely performed the same function as it did separately. Thus, one of ordinary skill in the art would have recognized that, given existing technical ability to combine the elements, as evidenced by Lewis in view of Zhang and Daly above, the to- be combined elements would have fit together like pieces of a puzzle in a logical, complementary, technologically feasible and/or economically desirable manner. Thus, it would have been reasoned that the results of the combination would have been predictable (see MPEP 2143 A).
Regarding claims 10, 20: Lewis / Zhang / Daly teaches all the limitations of claims 9, 19 above.
Lewis further teaches:
wherein the assignment filtering module confirms (claim 10) / confirming, by the assignment filtering module (claim 20), employment status of the team leaders in the team leader list based on an on-duty employee list in the assignment database and updates the team leader list based on on-duty status of the team leaders (Lewis ¶ [0133]: ‘Employees List’: allows users to sort, select, and view other users they have affiliated with, as well as control privacy settings and search for and add new users or groups. ¶ [0136]: ‘Clock In/Out’: allows users to clock in or out of their various affiliations, meaning that a user is able to manage their privacy and Submission settings for all affiliations the user belongs to. ‘Clocking In' represents enabling the authorized affiliation to view the user on the map and view submissions that are sent to this affiliation, while ‘Clocking Out' represents disabling the authorized affiliation from viewing any user-related information, including but not limited to: GPS location, Data Submissions, Location Information, and Messaging).
Regarding claim 21: Lewis / Zhang / Daly teaches all the limitations of claim 11 above.
Lewis further teaches a non-transitory computer readable medium, storing program code, executable by a computing device or computer (see Lewis ¶ [0025]) for performing the functions of claim 11 as rejected above.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Conclusion
The following art is made of record and considered pertinent to Applicant’s disclosure:
Benoit; Olivier Jean et al. US 20150229475 A1, Assisted device provisioning in a network.
WEISS; Alexander et al. US 20210167954 A1, Management of encryption key updates based on activity of a user group.
Garigan; Maeve et al. US 20240057102 A1, Configuration of an ephemeral secure wireless ad-hoc network for programmable devices.
FERRIER; Andrew et al. US 20240020670 A1, System and method for pairing devices to establish device groups.
Manouchehri; Ali Reza et al. US 11960283 B1, Drone authorization and management.
Cong et al. CN 116795499 A, Mobile equipment team action control method and system.
Reslan, Maya, et al. "A data-driven framework for team formation for maintenance tasks." International Journal of Prognostics and Health Management 12.1 (2021).
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Any inquiry concerning this communication or earlier communications from the examiner should be directed to REED M. BOND whose telephone number is (571) 270-0585. The examiner can normally be reached Monday - Friday 8:00 am - 5:00 pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Patricia Munson can be reached at (571) 270-5396. 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.
/REED M. BOND/Examiner, Art Unit 3624 February 1, 2026
/HAMZEH OBAID/Primary Examiner, Art Unit 3624 February 3, 2026
1 MPEP 2106.04(a): “examiners should identify at least one abstract idea grouping, but preferably identify all groupings to the extent possible”.