DETAILED ACTION
Status of the Claims
The following is a Non-final Office Action in response to amendments and remarks filed 06 November 2025.
Claims 1-2, 12-16, 18-21, 23 and 25 have been amended.
Claims 3-11, 17, and 24 have been cancelled.
Claims 1-2, 12-16, 18-23, and 25 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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 06 November 2025 has been entered.
Response to Arguments
Applicants argue that the 35 U.S.C. 101 rejection under the Alice Corp. vs. CLS Bank Int’l be withdrawn; however the Examiner respectfully disagrees. The Examiner notes that in order to be patent eligible under 35 U.S.C. 101, the claims must be directed towards a patent eligible concept, which, the instant claims are not directed. Applicant makes several arguments that the claims are not a mental process and the Examiner agrees, as no such assertion has been made by the Examiner. Next, and contrary to Applicants’ assertion that the claims are not a certain method of organizing human activity, the Examiner notes that fostering design phases of a product through group collaboration is a function that research and development, employers, science teachers, design teams, labs “think tanks” etc. have traditionally performed/provided for users, collaborators, inventors etc. Next, the claims are not directed to a practical application of the concept. The claims do not result in improvements to the functioning of a computer or to any other technology or technical field. They do not effect a particular treatment for a disease. They are not applied with or by a particular machine. They do not effect a transformation or reduction of a particular article to a different state or thing. And they are not applied in some other meaningful way beyond generally linking the use of the judicial exception (i.e., creating teams and generating an interactive space) to a particular technological environment (i.e., virtually or over the Internet). Here, again as noted in the previous rejection, mere instructions to apply an exception using a generic computer component cannot provide an inventive concept - MPEP 2016.05(f). The claims recitation of the “a storage unit,” “an interaction system,” “at least one processor,” “a memory coupled to the at least one processor…” and “a synchronous interactive virtual space” only generally linking the use of the judicial exception to a particular technological environment or field of use – see MPEP 2106.05(h). The Examiner also notes, again, method claim 1 is devoid of structure whosever and thus can only be directed towards an abstract idea (a system can still be only software in nature and does not necessarily imply any tangible structure). As such, this argument is not persuasive, and the claim(s) is/are not patent eligible.
Applicants further argues that the claims amount to significantly more however the Examiner respectfully disagrees and in particular, the claims are not directed to overcoming a problem specifically arising in the realm of computer networks. Such a computer technology problem is, for example, a problem concerning processor efficiency whereby a possible claim solution optimizes placement and routing procedures. To determine whether an invention claims ineligible subject matter, we engage in a two-step process. First, “we determine whether the claims at issue are directed to one of [the] patent ineligible concepts”—laws of nature, natural phenomena, or abstract ideas. Id. at 2355. “The ‘abstract ideas’ category embodies ‘the longstanding rule’ that ‘[a]n idea of itself is not patentable.’” Id. (quoting Gottschalk v. Benson, 409 U.S. 63, 67 (1972)). An abstract idea does not become non abstract by limiting the invention to a particular field of use or technological environment, such as the Internet. See Alice, 134 S. Ct. at 2358 (limiting an abstract idea to a particular technological environment, such as a computer, does not confer patent eligibility); Bilski v. Kappos, 561 U.S. 593, 612 (2010) (“[L]imiting an abstract idea to one field of use . . . d[oes] not make the concept patentable.”). If it is determined that the patent is drawn to an abstract idea or otherwise ineligible subject matter, at a second step we ask whether the remaining elements, either in isolation or combination with the non-patent ineligible elements, are sufficient to “‘transform the nature of the claim’ into a patent-eligible application.” Alice, 134 S. Ct. at 2358 (quoting Mayo Collaborative Servs. v. Prometheus Labs., Inc., 132 S. Ct. 1289, 1297 (2012)). Put another way, there must be an “inventive concept” to take the claim into the realm of patent eligibility. Id. at 2355. A simple instruction to apply an abstract idea on a computer is not enough. Alice, 134 S. Ct. at 2358 (“[M]ere recitation of a generic computer cannot transform a patent-ineligible idea into a patent eligible invention. Stating an abstract idea ‘while adding the words “apply it’’ is not enough for patent eligibility.’” (quoting Mayo, 132 S. Ct. at 1294)). Applicants’ claims use a at least one processor pertaining to the abstract idea of “organizing human activities’ involving forming groups for a design of a product. Here, the claimed solution is directed to the abstract idea of “organizing human activities’ involving creating groups and interactive environments which is not necessarily rooted in computer technology (group collaboration for projects or product design is not solely unique to the Internet). Further, the at least one processors are only used generically; a simple instruction to apply an abstract idea is not enough, regardless of traditional business analog. As such, this argument is not persuasive and the rejection was not withdrawn.
Applicant’s arguments appear to be whether or not the use of computer or computing components for increased speed and efficiency integrates the claims or amounts to significantly more/an inventive concept; however the Examiner respectfully disagrees. Nor, in addressing the second step of Alice, does claiming the improved speed or efficiency inherent with applying the abstract idea on a computer provide a sufficient inventive concept. See Bancorp Servs., LLC v. Sun Life Assurance Co. of Can., 687 F.3d 1266, 1278 (Fed. Cir. 2012) (“[T]he fact that the required calculations could be performed more efficiently via a computer does not materially alter the patent eligibility of the claimed subject matter.”); CLS Bank, Int’l v. Alice Corp., 717 F.3d 1269, 1286 (Fed. Cir. 2013) (en banc) aff’d, 134 S. Ct. 2347 (2014) (“[S]imply appending generic computer functionality to lend speed or efficiency to the performance of an otherwise abstract concept does not meaningfully limit claim scope for purposes of patent eligibility.” (citations omitted)).
Applicant argues that the instant claimed process and function are different from that of the cited references; however the Examiner respectfully disagrees for a plurality of reasons. Firstly, a recitation of the intended use of the claimed invention must result in a structural difference between the claimed invention and the prior art in order to patentably distinguish the claimed invention from the prior art. If the prior art structure (or system or method) is capable of performing the intended use, then it meets the claim. Secondly, and contrary to Applicant’s assertions, Fairfax does in fact discuss the different ways for collaboration not only within the competition but also for the individual teams developing solutions “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).” Fairfax and the instant disclosure both discuss a need for and solution for how to have competitions. As such, this argument is not persuasive, and the rejection not withdrawn.
Next Applicant argues much more narrowly than actually claimed. For example, nothing in the claims specifically limits the “product design process” from a software product, nor does it specifically limit the product to being a physical, tangible product. As such, this argument is not persuasive, and the rejection not withdrawn.
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 § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-2, 12-16, 18-23, and 25 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 recites the limitation "the synchronous interactive space" in lines 17 and 20-21. There is insufficient antecedent basis for this limitation in the claim.
Claim 2 recites the limitation "the synchronous interactive space" in lines 24 and 27. There is insufficient antecedent basis for this limitation in the claim.
Claims 12-16, 18-23, and 25 are also rejected for failing to remedy the deficiencies of claims 1 and 2.
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-2, 12-16, 18-23, and 25 is/are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claims are directed to a process (an act, or series of acts or steps), a machine (a concrete thing, consisting of parts, or of certain devices and combination of devices), and a manufacture (an article produced from raw or prepared materials by giving these materials new forms, qualities, properties, or combinations, whether by hand labor or by machinery). Thus, each of the claims falls within one of the four statutory categories (Step 1). However, the claim(s) recite(s) generating a collaborative environment for design phases of a product by facilitate interaction among the at least one user based on the reply received from the at least one user to create a group of users and generating an interactive space which is an abstract idea of organizing human activities.
The limitations of “receiving a request from a first type of user for designing a product, wherein the request is indicative of at least one of a subject matter for a discussion, a need for a product to be developed or designed, details of a project to be completed; identifying, one or more second type of users based on the request and type of project to be designed, wherein the request is directed to the identified one or more second type of users; receiving a response from each of the one or more second type of users for the request, wherein the response comprises at least one of suggestions, willingness to design, enquiring additional details with respect to the product designing and providing details about alternate available design solutions; creating, a virtual team automatically to facilitate interaction among the one or more second type of users based on the response; and generating, a synchronous interactive virtual space for the virtual team for performing one or more actions with respect to stages of designing the requested product, wherein the synchronous interactive space includes a plurality of collaborative interactive designing tools for performing the one or more actions, wherein the plurality of collaborative interactive designing tools comprise at least one of multi-user collaborative whiteboard, 3D model, image sharing and mind map, wherein the synchronous interactive space provides real-time communication of the one or more actions between the one or more second type of users during each stage of the design, simultaneous and synchronized access and control of the plurality of collaborative interactive designing tools with one or more second type of users during the designing of the product,” as drafted, is a process that, under its broadest reasonable interpretation, covers organizing human activities--fundamental economic principles or practices (including hedging, insurance, mitigating risk); commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations); managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions) but for the recitation of generic computer components (Step 2A Prong 1). Method claim 1 is devoid of structure whatsoever. Regarding claim 2, other than reciting “a system for product generating a real-time collaborative environment for early design phases of a product, 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:” in claim 2 language, “receiving,” “identifying,” “creating,” and “generating,” in the context of this claim encompasses the user organizing users for some sort of prototype design activity which is a form of managing personal behavior or interactions between people, as well as a collaborative business relation. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation as a certain method of organizing human activity but for the recitation of generic computer components, then it falls within the “Certain Methods or Organizing Human Activities” grouping of abstract ideas. Accordingly, the claim(s) recite(s) an abstract idea.
This judicial exception is not integrated into a practical application (Step 2A Prong Two). Method claim 1 is devoid of structure whatsoever and thus cannot be integrated into a practical application. Next, claim 2 only recites one additional element – using at least one processor to perform the steps. The at least one processor in the steps is recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer component. Specifically the claims amount to nothing more than an instruction to apply the abstract idea using a generic computer or invoking computers as tools by adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.04(d)(I) discussing MPEP 2106.05(f). The claims recitation of the “a storage unit,” “an interaction system,” “at least one processor,” “a memory coupled to the at least one processor…” “a synchronous interactive virtual space” and “wherein the system provides a synchronous multiuser access control within the synchronous interactive virtual space to the one or more second type of users for designing the requested product” is only generally linking the use of the judicial exception to a particular technological environment or field of use – see MPEP 2106.04(d)(I) discussing MPEP 2106.05(h). Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea, even when considered as a whole.
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception (Step 2B). Method claim 1 is devoid of structure whatsoever and thus cannot amount to significantly more. As discussed above with respect to integration of the abstract idea into a practical application (Step 2A Prong 2), the additional element of using at least one processor to perform the steps amounts to no more than mere instructions to apply the exception using a generic computer component. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The claim(s) is/are not patent eligible, even when considered as a whole.
Claims 12-16, 18-23, and 25 recite the additional limitations further including different steps/modules with functionality that are all still directed towards the abstract idea previously identified and is not an inventive concept that meaningfully limits the abstract idea. Again, as discussed with respect to claims 1 and 2, the claims are simply limitations which are no more than mere instructions to apply the exception using a computer or with computing components. Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Even when considered as a whole, the claims do not integrate the judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B.
Claims 1-2, 12-16, 18-23, and 25 are therefore not eligible subject matter, even when considered as a whole.
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, 18-23, and 25 is/are rejected under 35 U.S.C. 103 as being unpatentable over Fairfax et al. (US PG Pub. 2010/0178978) and further in view of Abebe et al. (US PG Pub. 2018/0068271).
As per claims 1 and 2, Fairfax discloses A method for generating a real-time collaborative environment for early design phases of a 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):
receiving, by a system, a request from a first type of user for designing a product, wherein the request is indicative of at least one of a subject matter for a discussion, a need for a product to be developed or designed, details of a project to be completed (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);
identifying, by the system, one or more second type of users based on the request and type of project to be designed, wherein the request is directed to the identified one or more second type of 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 system, a response from each of the one or more second type of users for the request, wherein the response comprises at least one of suggestions, willingness to design, enquiring additional details with respect to the product designing and providing details about alternate available design solutions (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 system, a synchronous interactive virtual space for the virtual team for performing one or more actions with respect to stages of designing the requested product, wherein the synchronous interactive space includes a plurality of collaborative interactive designing tools for performing the one or more actions, wherein the plurality of collaborative interactive designing tools comprise at least one of multi-user collaborative whiteboard, 3D model, image sharing and mind map, wherein the synchronous interactive space provides real-time communication of the one or more actions between the one or more second type of users during each stage of the design, simultaneous and synchronized access and control of the plurality of collaborative interactive designing tools with one or more second type of users during the designing of the product, wherein the system provides a synchronous multiuser access control within the synchronous interactive virtual space to the one or more second type of users for designing the requested 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);
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 creating, by the system, a virtual team automatically to facilitate interaction among the one or more second type of users based on the response (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).
As per claims 12 and 19, Fairfax and Abebe disclose as shown above with respect to claims 1 and 2. Abebe further teaches identifying previously generated designs from product design projects stored in a database, based on the request; providing automatic suggestions regarding the one or more second type of 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 of 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 and Abebe disclose as shown above with respect to claims 1 and 2. Abebe further teaches providing automatic suggestions regarding the plurality of collaborative interactive designing tools in a virtual team space to the one or more second type of users during synchronous 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 and Abebe disclose as shown above with respect to claims 1 and 2. Abebe further teaches based on the request, providing suggestions regarding the other second type of users with respect to product designs in the system, to the virtual team; automatically providing invitations to the one or more second type of users and suggesting the one or more second type of user to the first type of user to invite the other second type of users; and capturing project information of product design projects stored in a database and displaying a number of completed design projects and number of ongoing design projects of the suggested other 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 and Abebe disclose as shown above with respect to claims 1 and 2. Fairfax further discloses identifying fabrication entities automatically from product design projects and associated activities, and providing suggestions to the first type of user; and identifying incubation centres for the product design based on 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 and Abebe 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 one or more second type of 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).
As per claims 18 and 25, Fairfax and Abebe disclose as shown above with respect to claims 1 and 2. Fairfax further discloses providing experimentation-based learning by: providing a virtual experimentation environment for self-experimentation with respect to one or more curriculum; and storing results of the experimentation and information of one or more attempts until the experimentation is successful (As non-limiting illustrative examples, an asset may be a software program, logo, graphic design, specification, requirements document, wireframe, static prototype, working prototype, architecture design, component design, implemented component, assembled or partially-assembled application, testing plan, test cases, test code, documentation, and so on, Fairfax ¶62; testing prototypes, ¶89; testing software modules, ¶142) (Examiner notes the testing of plans/cases of prototypes as the ability to perform virtual experimentations).
Conclusion
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