DETAILED ACTION
Status of the Claims
The following is a Final Office Action in response to amendments and remarks filed 14 July 2026.
Claims 1-2, 12-16, and 19-23 have been amended.
Claims 18 and 25 have been cancelled.
Claims 1-2, 12-16, and 19-23 are pending and have been examined.
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 Arguments
Applicant argues that the 35 U.S.C. 101 rejection under the Alice Corp. vs. CLS Bank Int’l be withdrawn; however, and in light of the amendments, the arguments are persuasive. The amendments now integrate the claims into a practical application by establishing a synchronous multi-user visual design interaction system. As such, the rejection has been withdrawn.
Applicant’s remarks with respect to the prior art have been fully considered but are moot on grounds of new rejection, as necessitated by amendments.
In response to arguments in reference to any depending claims that have not been individually addressed, all rejections made towards these dependent claims are maintained due to a lack of reply by the Applicants in regards to distinctly and specifically pointing out the supposed errors in the Examiner's prior office action (37 CFR 1.111). The Examiner asserts that the Applicants only argue that the dependent claims should be allowable because the independent claims are unobvious and patentable over the prior art.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (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.
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-2, 12-16, and 19-23 is/are rejected under 35 U.S.C. 103 as being unpatentable over Fairfax et al. (US PG Pub. 2010/0178978) further in view of Abebe et al. (US PG Pub. 2018/0068271) and Miller (US PG Pub. 2013/0120367).
As per claims 1 and 2, Fairfax discloses a computer-implemented method for providing synchronous multi-user generation and modification of visual design representations during early design phases of a physical product design process, the method comprising: a system for product designing through collaboration, the system comprising of: a storage unit; an interaction system communicably coupled with the storage unit; the interaction system comprising: at least one processor; and a memory coupled to the at least one processor, the memory comprising at least one instruction executable by the at least one processor, the at least one processor being operable when executing the instructions to: a method for product designing through collaboration employing a system for product designing, the method comprising: provisioning, by an interaction system, an access to at least one user, the interaction system communicably coupled with a storage unit and comprising at least one processor and memory; (competition management system servers interact with clients, computers with data storage, server, Fairfax ¶146; see also Fig. 7; these subsystems may communicate with a database 870, which may be any suitable commercial-grade database. In some embodiments, a data warehouse 872 may be used to store competition registration and completion data, for access and analysis by the prediction subsystem, ¶155; competition registration process, ¶11; Although described here with reference to software, and useful when implemented with regard to software assets, the cooperatively developed product can be any sort of tangible or intangible object that embodies intellectual property. As non-limiting examples, the techniques could be used for computer hardware and electronics designs, or other designs such as architecture, construction, or landscape design. Other non-limiting examples for which the techniques could be used include the development of all kinds of written documents and content such as documentation and articles for papers or periodicals (whether on-line or on paper), research papers, scripts, multimedia content, legal documents, and more, ¶156):
providing, by an interaction system comprising at least one processor and a memory and communicatively coupled through a network to a first electronic device associated with a first- type user and a plurality of second electronic devices respectively associated with a plurality of second-type users, the first-type user and the plurality of second-type users with access to the interaction system (access to project based on roles, Fairfax ¶99; software, processor, ¶144; server, memory, ¶146);
receiving, by the interaction system from the first electronic device, a request for designing a physical product, the request indicating one or more of a subject matter for discussion, a need for the physical product to be developed or designed, and details of a physical-product design project (In other cases, the facilitator 1000 may be appointed or supplied by an entity requesting the development, and thus the entity requesting the competition oversees the competition. The facilitator 1000 has a specification 1010 for an asset to be developed by competition. In general, a specification 1010 is intended to have sufficient information to allow contestants to generate the desired asset. In some cases, the specification 1010 may include a short list of requirements. In some cases the specification may include the result of a previous competition, such as a design, wireframe, prototype, and so forth. In some cases, the specification may be the result of a previous competition along with a description of requested changes or additions to the asset. The facilitator 1000 may review the specification 1010, and format or otherwise modify it to conform to standards and/or to a development methodology. The facilitator 1000 may in some cases reject the specification for failure to meet designated standards. The facilitator 1000 may mandate that another competition should take place to change the specification 1010 so that it can be used in this competition. The facilitator 1000 may itself interact with the entity requesting the competition for further detail or information, Fairfax ¶63-¶64; the cooperatively developed product can be any sort of tangible or intangible object that embodies intellectual property, ¶156);
automatically identifying, by the interaction system, the plurality of second-type users based on the request and stored user-profile information for each of the plurality of second-type users, wherein the stored user-profile information identifies at least one of an area of interest and a specialty, of the corresponding second-type user (The recipients 1004 of the specification can be selected in various ways. In some embodiments, members of the community may have expressed interest in participating in a particular type of asset development competition, whereas in some cases individuals are selected based on previous performances in competitions, prior projects, and/or based on other methods of measuring programming skill of a software developer. For example, the members of the community may have been rated according to their performance in a previous competition and the ratings may be used to determine which programmers are eligible to receive notification of a new specification or respond to a notification. The community members may have taken other steps to qualify for particular competitions, for example, executed a non-disclosure agreement, provided evidence of citizenship, submitted to a background check, and so forth. Recipients may need to register for a competition in order to gain access, Fairfax ¶68);
transmitting, by the interaction system, the request to the plurality of second electronic devices associated with the identified second-type users (The recipients 1004 of the specification can be selected in various ways. In some embodiments, members of the community may have expressed interest in participating in a particular type of asset development competition, whereas in some cases individuals are selected based on previous performances in competitions, prior projects, and/or based on other methods of measuring programming skill of a software developer. For example, the members of the community may have been rated according to their performance in a previous competition and the ratings may be used to determine which programmers are eligible to receive notification of a new specification or respond to a notification. The community members may have taken other steps to qualify for particular competitions, for example, executed a non-disclosure agreement, provided evidence of citizenship, submitted to a background check, and so forth. Recipients may need to register for a competition in order to gain access, Fairfax ¶68);
receiving, by the interaction system from the plurality of second electronic devices,, a respective response from each of the identified second-type users, wherein the respective response indicates one or more of a suggestion, willingness to participate in designing the physical product,, a request for additional product-design information, and an alternate design solution (In one embodiment, a facilitator 1000 moderates a collaborative discussion forum among the various participants to answer questions and/or to facilitate development by the contestants. The collaborative forum can include such participants as facilitators, developers, customers, prospective customers, and/or others interested in the development of certain assets. In one embodiment, the collaboration forum is an online forum where participants can post ideas, questions, suggestions, or other information. In some embodiments, only a subset of the members can post to the forum, for example, participants in a particular competition or on a particular team, Fairfax ¶69);
generating, by the interaction system, a synchronous interactive virtual space to perform design actions during respective stages of designing the physical product (a facilitator 1000 moderates a collaborative discussion forum among the various participants to answer questions and/or to facilitate development by the contestants. The collaborative forum can include such participants as facilitators, developers, customers, prospective customers, and/or others interested in the development of certain assets. In one embodiment, the collaboration forum is an online forum where participants can post ideas, questions, suggestions, or other information. In some embodiments, only a subset of the members can post to the forum, for example, participants in a particular competition or on a particular team, Fairfax ¶69; dashboard, ¶98; the web site project-specific public or private `group` pages, generated by the customer from the cockpit, on which the nature of the project can be described, relevant attachments can be viewed, and the customer can openly communicate with members via a bulletin board or forum to answer questions, receive suggestions, and so on. In some embodiments, these pages allow participants to see the evolution of the project, interact, collaborate, provide status reports, and make delivery, ¶98-¶102; see also requirements document, ¶62; required files, formats, ¶74) (Examiner notes the dashboard with collaboration tools such as bulletin boards, widgets, discussion forums etc. as the interactive design tools such as a multi-user collaborative whiteboard, image sharing and mind map that provides real-time communications and notifications);
providing, by the interaction system within the synchronous interactive virtual a real-time shared space comprising a multi-user collaborative whiteboard tool menu (dashboard, Fairfax ¶98; the web site project-specific public or private `group` pages, generated by the customer from the cockpit, on which the nature of the project can be described, relevant attachments can be viewed, and the customer can openly communicate with members via a bulletin board or forum to answer questions, receive suggestions, and so on. In some embodiments, these pages allow participants to see the evolution of the project, interact, collaborate, provide status reports, and make delivery, ¶98-¶102; see also requirements document, ¶62; required files, formats, ¶74).
Fairfax does not expressly disclose creating, by the system, a virtual team automatically to facilitate interaction among the one or more second type of users based on the response.
However, Abebe teaches automatically, creating, by the interaction system and based on the respective responses, a virtual team comprising at least two of the identified second-type users (A system and method may be presented that trains a computer to automatically determine optimal team structures and provide tuning suggestions for related processes, for example, based on: 1) mined information about individuals including skills, career goals, and social profiles; 2) team dynamics inferred from past interaction and personalities from individuals; 3) project metadata including requirements and technical details, Abebe ¶11; team that is located remotely, ¶69) (Examiner notes the remote aspect of the Abebe reference to read upon the virtual group).
Both the Fairfax and Abebe references are analogous in that both are directed towards/concerned with facilitating collaborative design solutions. Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to use Abebe’s ability to automatically assemble a team in Fairfax’s system to improve the system and method with reasonable expectation that this would result in a design management system that is able to allow for a more remote collaboration.
The motivation being that identifying ideal team composition and structure has bearing on efficiency and effectiveness of software project and any other type of projects that involves a group of people undertaking an activity. While this problem is challenging in general it becomes even worse in a context whereby agile methodologies are applied. In agile software development, requirements and solutions evolve through the collaborative effort of self-organizing cross-functional teams. Agile methodologies demand a considerable amount of collaboration and are designed to embrace change. This change might bring about different requirements which demand changes in team composition and structure. The optimality of a team composition and structure is determined by a myriad of factors including: skill levels of individuals, experiences of team members working together, personalities, code styles and life styles (specifically in geographically dispersed teams). The current methodologies or approaches rely primarily on the judgment of team leads and project managers during the setup phase and on measurements of past performance and while adapting workload as the project progresses. Those approaches fail to account for all relevant factors, leading to sub-optimal team composition and inefficiencies in project outcomes (Abebe ¶2).
The combination of Fairfax and Abebe do not expressly disclose providing, by the interaction system within the synchronous interactive virtual a real-time shared space comprising a multi-user collaborative whiteboard tool menu and three-dimensional (3D) model tool menu for generating and modifying the visual design representations, wherein the visual design representations comprise at least one of a sketch, a drawing, an image, a computer-aided-design model, a two-dimensional model, and a three-dimensional model;; providing, by the interaction system, synchronized access to and control of the real-time shared space, wherein providing the synchronized access and control comprises: receiving, from one of the second electronic devices, a selection to switch from a currently displayed one of the multi-user collaborative whiteboard tool menu and the 3D model tool menu to the other one of the multi-user collaborative whiteboard tool menu and the 3D model tool menu; in response to receiving the selection, causing the selected other one of the multi- user collaborative whiteboard tool menu and the 3D model tool menu to be displayed at each of the second electronic devices associated with the virtual team; concurrently receiving, through the multi-user collaborative whiteboard tool menu, respective drawing inputs from at least two of the second electronic devices; causing changes resulting from the respective drawing inputs to be displayed in real time at each of the second electronic devices together with a user name and a pointer location associated with each respective drawing input; receiving, through the 3D model tool menu, a modification of a three-dimensional model from one of the second electronic devices; and causing the three-dimensional model presented at each of the other second electronic devices associated with the virtual team to change in real time according to the modification; and storing, in a storage unit communicatively coupled to the interaction system, information associated with the virtual team and the visual design representations generated or modified within the synchronous interactive virtual space.
However, Miller teaches:
providing, by the interaction system within the synchronous interactive virtual a real-time shared space comprising a multi-user collaborative....three-dimensional (3D) model tool menu for generating and modifying the visual design representations, wherein the visual design representations comprise at least one of a sketch, a drawing, an image, a computer-aided-design model, a two-dimensional model, and a three-dimensional model (In embodiments where the development system is collaborative, the 3D model development system may provide collaborative functionality via an application programming interface (API), Miller ¶21; real-time collaborating multi-users, ¶25-¶26);;
providing, by the interaction system, synchronized access to and control of the real-time shared space, wherein providing the synchronized access and control comprises (a method for facilitating a real-time shared viewing experience in a three-dimensional (3D) modeling environment includes receiving a local viewpoint modification indication indicating that a viewpoint of a three-dimensional (3D) model has been locally modified at a first computing device. The 3D model may be represented by model data that includes component data corresponding to a plurality of respective components of the 3D model, and the component data may include element data representing a plurality of respective sets of edges and faces corresponding to the plurality of respective components. The viewpoint of the 3D model may correspond to a positioning of a rendering of the 3D model relative to a plane of a display device at the first computing device, and the rendering may be based on the model data. In an embodiment, the method includes generating, in response to the received local viewpoint modification indication, a viewpoint update indication descriptive of the modified viewpoint. The method may further include causing the viewpoint update indication to be transmitted to a second computing device. The 3D model may be rendered on a display device at the second computing device according to the modified viewpoint and the model data, in an embodiment, Miller ¶9):
receiving, from one of the second electronic devices, a selection to switch from a currently displayed one of the multi-user collaborative whiteboard tool menu and the 3D model tool menu to the other one of the multi-user collaborative whiteboard tool menu and the 3D model tool menu (a method for facilitating a real-time shared viewing experience in a three-dimensional (3D) modeling environment includes receiving a local viewpoint modification indication indicating that a viewpoint of a three-dimensional (3D) model has been locally modified at a first computing device. The 3D model may be represented by model data that includes component data corresponding to a plurality of respective components of the 3D model, and the component data may include element data representing a plurality of respective sets of edges and faces corresponding to the plurality of respective components. The viewpoint of the 3D model may correspond to a positioning of a rendering of the 3D model relative to a plane of a display device at the first computing device, and the rendering may be based on the model data. In an embodiment, the method includes generating, in response to the received local viewpoint modification indication, a viewpoint update indication descriptive of the modified viewpoint. The method may further include causing the viewpoint update indication to be transmitted to a second computing device. The 3D model may be rendered on a display device at the second computing device according to the modified viewpoint and the model data, in an embodiment, Miller ¶9);
in response to receiving the selection, causing the selected other one of the multi- user collaborative whiteboard tool menu and the 3D model tool menu to be displayed at each of the second electronic devices associated with the virtual team (In embodiments where the 3D modeling application 50a supports collaborative development, the 3D modeling application 50a includes an interface via which certain functionality and data structures of the 3D modeling application 50a are made accessible to other programs, so that the functionality of the 3D modeling application 50 may be extended to include additional features. In an embodiment, a collaboration Application Programming Interface (API) 52 provides collaboration capability to the 3D modeling application 50a, so that a user operating the client device 12 and another user operating the client device 14 can develop a 3D model together during essentially the same time interval. The collaboration API 52 may include functions for inviting collaborators, generating component modification updates, locking and unlocking components for conflict-free editing, generating a representation of a component in a serialized format for sharing with another client device, etc., Miller ¶37);
concurrently receiving, through the multi-user collaborative whiteboard tool menu, respective drawing inputs from at least two of the second electronic devices (In embodiments where the development system is collaborative, the 3D model development system may provide collaborative functionality via an application programming interface (API));
causing changes resulting from the respective drawing inputs to be displayed in real time at each of the second electronic devices together with a user name and a pointer location associated with each respective drawing input (These changes or modifications in viewpoint may be automatically propagated to the other collaborating users, so that the viewpoint of the 3D model on each of the computing devices used by respective other users may be congruent or consistent in real-time with the viewpoint that is being displayed on the computing device used by the first user. As such, the other users may share the viewpoint of the first user in real-time, and communication and/or development may be enhanced, efficient and productive. In some embodiments, only one of multiple collaborating users (or only one of the multiple computing devices used by the multiple users) may control the viewpoint modification of the 3D model (e.g., control of the "virtual camera") at a time to avoid conflicts, Miller ¶25);
receiving, through the 3D model tool menu, a modification of a three-dimensional model from one of the second electronic devices (These changes or modifications in viewpoint may be automatically propagated to the other collaborating users, so that the viewpoint of the 3D model on each of the computing devices used by respective other users may be congruent or consistent in real-time with the viewpoint that is being displayed on the computing device used by the first user. As such, the other users may share the viewpoint of the first user in real-time, and communication and/or development may be enhanced, efficient and productive. In some embodiments, only one of multiple collaborating users (or only one of the multiple computing devices used by the multiple users) may control the viewpoint modification of the 3D model (e.g., control of the "virtual camera") at a time to avoid conflicts, Miller ¶25); and
causing the three-dimensional model presented at each of the other second electronic devices associated with the virtual team to change in real time according to the modification (These changes or modifications in viewpoint may be automatically propagated to the other collaborating users, so that the viewpoint of the 3D model on each of the computing devices used by respective other users may be congruent or consistent in real-time with the viewpoint that is being displayed on the computing device used by the first user. As such, the other users may share the viewpoint of the first user in real-time, and communication and/or development may be enhanced, efficient and productive. In some embodiments, only one of multiple collaborating users (or only one of the multiple computing devices used by the multiple users) may control the viewpoint modification of the 3D model (e.g., control of the "virtual camera") at a time to avoid conflicts, Miller ¶25); and
storing, in a storage unit communicatively coupled to the interaction system, information associated with the virtual team and the visual design representations generated or modified within the synchronous interactive virtual space (These changes or modifications in viewpoint may be automatically propagated to the other collaborating users, so that the viewpoint of the 3D model on each of the computing devices used by respective other users may be congruent or consistent in real-time with the viewpoint that is being displayed on the computing device used by the first user. As such, the other users may share the viewpoint of the first user in real-time, and communication and/or development may be enhanced, efficient and productive. In some embodiments, only one of multiple collaborating users (or only one of the multiple computing devices used by the multiple users) may control the viewpoint modification of the 3D model (e.g., control of the "virtual camera") at a time to avoid conflicts, Miller ¶25).
The Fairfax, Abebe, and Miller references are analogous in that both are directed towards/concerned with facilitating collaborative design solutions. Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to use Miller’s ability to incorporate 3D designs in Abebe and Fairfax’s system to improve the system and method with reasonable expectation that this would result in a design management system that is able to allow for a more remote collaboration.
The motivation being that there is a need to allow multiple users to collaborate within a 3D environment as users usually develop 3D models by sequentially entering various drawing and image manipulation commands via a graphical user interface (GUI). For example, to model a two-story building, a user may first draw a four-wall structure, draw a door in one of the walls, then draw several windows in the walls, etc. The user may then paint or texture the walls, the roof, and other portions of the model. Accordingly, it may take a significant amount of time for a single user to develop a complex and detailed model (Miller ¶7).
In addition, the Examiner asserts that claim scope is not limited by claim language that suggests or makes optional but does not require steps to be performed, or by claim language that does not limit a claim to a particular structure. However, examples of claim language, although not exhaustive, that may raise a question as to the limiting effect of the language in a claim are: (A) "adapted to" or "adapted for" clauses; (B) "wherein" clauses; and (C) "whereby" clauses (See MPEP 2111.04). In the instant case, the recited "causing changes resulting from the respective drawing inputs to be displayed in real time at each of the second electronic devices together with a user name and a pointer location associated with each respective drawing input; receiving, through the 3D model tool menu, a modification of a three-dimensional model from one of the second electronic devices; and causing the three-dimensional model presented at each of the other second electronic devices associated with the virtual team to change in real time according to the modification; and storing, in a storage unit communicatively coupled to the interaction system, information associated with the virtual team and the visual design representations generated or modified within the synchronous interactive virtual space" is not a positive method step as it do not require any actual positive recited claim steps to be performed; nor does it modify any of the positively claimed method steps as they are modifying or depending upon a single Markush group option. Similarly, the recited wherein clause is not a positive system element since it doesn’t structurally limit the system and merely describes the intended use of the system and/or the intended result of the use of the system.
As per claims 12 and 19, Fairfax, Abebe, and Miller disclose as shown above with respect to claims 1 and 2. Abebe further teaches identifying previously generated designs from physical-product design projects stored in a database, based on the request; providing automatic suggestions regarding the identified second-type users or entity details to the first type of user; and converting suggestions associated with the identified previously generated designs to an original mode of communication of the first-type user based on the request (the skillset profile builder 214 creates and maintains profile for each individual accessible within the system. The agile team recommender 234 may extract the following information: requirements, technology stack (e.g., platforms, languages and libraries), architecture or reference designs, and deployment targets. The team profile builder 216 inspects the history of interactions between individuals to identify familiarity across individuals, commonality and disparity of practices and style, personality profiles and compatibility, geography and work pattern. The agile team recommender 234 identifies team structure and processes by identifying the right frequencies of scrums based on the characteristics of the team and the length of iterations and by identifying the sub-team composition and structure for each specific tasks to be executed (e.g., pairing, code-reviews) based on career goals or performance reviews, skillset profile, interaction history, and/or others. Frequency of scrums refers to the cadence with which scrums are run. Briefly, a scrum is an iterative and incremental agile software development framework for managing product development, a methodology for handling complex projects that falls within the agile practices. Within this methodology it is conceived that project team members will gather together on a daily basis (i.e., “Daily Scrums”) to discuss about the tasks to be acted upon and current obstacles to problems. The daily cadence of scrums is effective when there are project team members that are fully trained, educated, and proficient in the scrum method or have embraced the agile practices. In one embodiment of the present disclosure, to compose a team from a heterogeneous set of people who may have different habits, goals, work practices, the parameter (frequency of scrums) is identified and adapted for the best outcome of the team, Abebe ¶53; Learning module 230 is a component that uses historical data of projects, teams and agile project templates to infer which template structure worked well for different team and project profiles. To do this the component in one embodiment uses several historical data points about projects and teams, extracted from the knowledge base components 222, 224 and 242, ¶61).
Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to use Abebe’s ability to automatically assemble a team based on team member history and project histories in Fairfax’s system to improve the system and method with reasonable expectation that this would result in a design management system that is able to allow for a more remote collaboration.
The motivation being that identifying ideal team composition and structure has bearing on efficiency and effectiveness of software project and any other type of projects that involves a group of people undertaking an activity. While this problem is challenging in general it becomes even worse in a context whereby agile methodologies are applied. In agile software development, requirements and solutions evolve through the collaborative effort of self-organizing cross-functional teams. Agile methodologies demand a considerable amount of collaboration and are designed to embrace change. This change might bring about different requirements which demand changes in team composition and structure. The optimality of a team composition and structure is determined by a myriad of factors including: skill levels of individuals, experiences of team members working together, personalities, code styles and life styles (specifically in geographically dispersed teams). The current methodologies or approaches rely primarily on the judgment of team leads and project managers during the setup phase and on measurements of past performance and while adapting workload as the project progresses. Those approaches fail to account for all relevant factors, leading to sub-optimal team composition and inefficiencies in project outcomes (Abebe ¶2).
As per claims 13 and 20, Fairfax, Abebe, and Miller disclose as shown above with respect to claims 1 and 2. Abebe further teaches providing automatic suggestions regarding the multi-user collaborative whiteboard tool menu and the 3D model tool menu within the synchronous interactive virtual space to the second type users during synchronous physical-product design sessions (Structure and process recommender 234 may provide the following recommendations based on the above-example mined data. Scrum agile methodology is chosen for the project because: 1) short project deadline requires shorter sprint cycles; 2) scrum enables high level of team communication which is important in this project because the team has diverse skill sets, have not worked together before and because the project's deadline is short; 3) a majority of the team is familiar with Scrum. For effective communication of all teams, a daily scrum standup meeting that accounts for the work time preferences and time zones is recommended in this example. A daily meeting is scheduled to compensate for the fact that scrum yields poor documentation. Due to data and source code export control regulation constraints the system in this example recommends using the DevOps pipeline that is provisioned in the client's geographic region, which is the same geographic region as the location of the majority of the team. One team member is identified as having had past experience leading Proof of Concept(s) (PoCs) with the client, and has technical experience in the platform. Moreover, his personality profile identifies him as an influencer and hence he is chosen to be a technical leader and scrum master. Sub teams are created based on a matching of the project component requirements and the skillsets of individuals while also accounting for the relationships and personalities of individuals. System notices a gap in people's skills and allocated roles and suggests learning modules and schedules, Abebe ¶70).
Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to use Abebe’s ability to automatically assemble a team based on team member history and project histories in Fairfax’s system to improve the system and method with reasonable expectation that this would result in a design management system that is able to allow for a more remote collaboration.
The motivation being that identifying ideal team composition and structure has bearing on efficiency and effectiveness of software project and any other type of projects that involves a group of people undertaking an activity. While this problem is challenging in general it becomes even worse in a context whereby agile methodologies are applied. In agile software development, requirements and solutions evolve through the collaborative effort of self-organizing cross-functional teams. Agile methodologies demand a considerable amount of collaboration and are designed to embrace change. This change might bring about different requirements which demand changes in team composition and structure. The optimality of a team composition and structure is determined by a myriad of factors including: skill levels of individuals, experiences of team members working together, personalities, code styles and life styles (specifically in geographically dispersed teams). The current methodologies or approaches rely primarily on the judgment of team leads and project managers during the setup phase and on measurements of past performance and while adapting workload as the project progresses. Those approaches fail to account for all relevant factors, leading to sub-optimal team composition and inefficiencies in project outcomes (Abebe ¶2).
As per claims 14 and 21, Fairfax, Abebe, and Miller disclose as shown above with respect to claims 1 and 2. Abebe further teaches based on the request, providing suggestions regarding one or more additional second type users with respect to product designs in the system, to the virtual team; automatically providing invitations to the one or more additional second type users and suggesting that one or more of the identified second type user to invite the other one or more additional second type users; and capturing project information of physical-product design projects stored in a database and displaying a number of completed physical-product design projects and number of ongoing physical-product design projects of the suggested additional second type of users (In the case Trello has been selected as a tool for task management a new collection of boards are created to manage the project and team members are invited to it. Such operations can be executed programmatically through the APIs exposed by the service. Tools for communication and task management may be used that provide their services through APIs. The communication and collaboration tool configurator 304 may be composed by a collection of modules (plug-ins) that taken a list of team members (e.g., identifier by email) sets up the service, thus making this component extensible to other tools and services that may be identified in the future, Abebe ¶81; Profile builder components, including the skillset profile builder 214, team profile builder 216 and project profile builder 218 analyze data mined from a number of data sources. The skillset profile builder 214 generates a team member knowledgebase 220. The team profile builder 216 generates teams knowledgebase 222. The project profile builder 218 generates a repository or knowledgebase of past projects 224, ¶19; display, ¶74).
Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to use Abebe’s ability to automatically assemble a team based on team member history and project histories in Fairfax’s system to improve the system and method with reasonable expectation that this would result in a design management system that is able to allow for a more remote collaboration.
The motivation being that identifying ideal team composition and structure has bearing on efficiency and effectiveness of software project and any other type of projects that involves a group of people undertaking an activity. While this problem is challenging in general it becomes even worse in a context whereby agile methodologies are applied. In agile software development, requirements and solutions evolve through the collaborative effort of self-organizing cross-functional teams. Agile methodologies demand a considerable amount of collaboration and are designed to embrace change. This change might bring about different requirements which demand changes in team composition and structure. The optimality of a team composition and structure is determined by a myriad of factors including: skill levels of individuals, experiences of team members working together, personalities, code styles and life styles (specifically in geographically dispersed teams). The current methodologies or approaches rely primarily on the judgment of team leads and project managers during the setup phase and on measurements of past performance and while adapting workload as the project progresses. Those approaches fail to account for all relevant factors, leading to sub-optimal team composition and inefficiencies in project outcomes (Abebe ¶2).
As per claims 15 and 22, Fairfax, Abebe, and Miller disclose as shown above with respect to claims 1 and 2. Fairfax further discloses identifying fabrication entities automatically from physical-product design projects and associated activities, and providing suggestions to the first type user; and identifying incubation centres for the physical-product design project based on a product design domain and location information (The collaborative forum can include such participants as facilitators, developers, customers, prospective customers, and/or others interested in the development of certain assets, Fairfax ¶69; see also ¶84-¶85 and ¶98) (Examiner notes the facilitators/developers/potential customers and/or others interested in the development of certain assets as including fabrication entities and incubation centres for the product design projects).
As per claims 16 and 23, Fairfax, Abebe, and Miller disclose as shown above with respect to claims 1 and 2. Fairfax further discloses enabling creation of the virtual team by displaying interested users among the identified second-type users; and showing submissions to organizers and enabling selection of winner position (In some embodiments, if a competition is determined to be likely to result in successful completion, the registration for the competition may be limited or closed to additional participants. In this way, a number of potential contestants may be allocated across a number of competitions. In some embodiments, one goal is to have enough participants that a competition will complete successfully but not more participants than are needed. This minimizes the number of people who compete but do not win, and also frees those participants to compete in other competitions, thereby allowing more work to get done, Fairfax ¶14; identify competition winner, ¶41).
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 ANDREW B WHITAKER whose telephone number is (571)270-7563. The examiner can normally be reached on M-F, 8am-5pm, EST.
If attempts to reach the examiner by telephone are unsuccessful, the Examiner’s supervisor, Lynda Jasmin can be reached on (571) 272-6782. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-
automated- interview-request-air-form
/ANDREW B WHITAKER/Primary Examiner, Art Unit 3629
Prosecution Insights