Here are comprehensive solutions for all 12 case studies and scenarios across all five weeks:
---
# β SOLUTIONS β Professional Practice Case Studies & Scenarios
---
## π WEEK 09 β Computer Crime & Fraud
---
### Case Study 1 β The Ransomware Attack on MediCare Hospital
**Q1: Type of computer crime and method of attack**
This is a **ransomware attack**, a form of malware-based extortion. The specific method was **spear phishing** β a targeted email tricked an administrator into clicking a malicious link, which installed ransomware that then propagated laterally across the hospital network using a **worm-like spreading mechanism**.
**Q2: Internal and external threat actors**
- **Internal:** The hospital administrator who clicked the phishing link (unintentional insider threat); IT management who failed to test backups.
- **External:** The ransomware operators/cybercriminal group who authored, deployed, and monetized the attack.
**Q3: Security measures that should have been in place**
- Regular, tested offline backups (following the **3-2-1 backup rule**)
- Email filtering and anti-phishing tools (e.g., DMARC, SPF, sandboxing)
- Multi-factor authentication (MFA) on all accounts
- Network segmentation to contain lateral movement
- Regular staff cybersecurity awareness training
- Endpoint Detection and Response (EDR) software
- Patch management policy to close known vulnerabilities
**Q4: Ethical and legal obligations β should they pay the ransom?**
**Recommendation: Do NOT pay.** Reasons:
- Payment guarantees nothing β decryption keys may not work; attackers may strike again
- It funds criminal organizations and incentivizes future attacks
- Legal obligations include: notifying regulators (HIPAA/data protection law), informing affected patients, and preserving evidence for law enforcement
- Ethically, paying may violate sanctions if attackers are state-linked groups
**Q5: Immediate and long-term remediation steps**
| Immediate (0β72 hrs) | Long-term (1β6 months) |
|---|---|
| Isolate infected systems from the network | Implement tested backup schedule (3-2-1 rule) |
| Contact law enforcement (FBI/CISA) | Deploy EDR and SIEM solutions |
| Engage incident response firm | Mandatory phishing awareness training |
| Activate paper-based emergency protocols | Network segmentation and zero-trust architecture |
| Notify patients and regulators | Third-party penetration testing annually |
**Role-Play β Recommendation to Board (Refuse Payment):**
> "As IT Security Manager, I recommend we do not pay the ransom. Paying funds criminal activity, does not guarantee data recovery, and may violate federal sanctions. Instead, we should activate our incident response plan, contact the FBI Cyber Division, restore from our most recent clean backup β even if partial β and operate on emergency paper protocols during recovery. The reputational and legal cost of payment outweighs that of a structured, transparent recovery."
---
### Case Study 2 β The Insider Threat at FinTech Solutions
**Q1: Laws violated**
- **Computer Fraud and Abuse Act (CFAA)** β unauthorized copying of data for personal gain
- **Data Protection/Privacy Laws** (e.g., GDPR if applicable, or national equivalents) β breach of 200,000 customer records
- **Trade Secrets Act** β misappropriation of proprietary business data
- **Criminal laws** β theft, breach of contract, potentially wire fraud
**Q2: Intentional vs. unintentional insider threats**
- **Unintentional:** An employee accidentally leaks data (e.g., clicks a phishing link, misconfigures a server)
- **Intentional:** A malicious actor deliberately exfiltrates data for personal gain
- This case is **intentional** β the developer was motivated by revenge and financial gain
**Q3: Technical controls that could have prevented this**
- **Data Loss Prevention (DLP)** tools β flag or block bulk data transfers to USB
- **USB port restrictions** β disable removable media via Group Policy
- **Access logging and auditing** β alerts on large database exports
- **Least privilege principle** β limit database access to only what the role requires
- **Immediate access revocation** upon resignation/termination (offboarding checklist)
**Q4: Consequences**
- **Company:** Regulatory fines, lawsuits from affected customers, reputational damage, loss of business
- **Developer:** Criminal prosecution, civil liability, imprisonment, permanent career damage
- **Customers:** Identity theft, financial fraud, emotional distress
**Q5: Security Awareness Policy β Insider Threats**
Key components: define insider threat types; mandatory training on data handling; clear acceptable-use policy; offboarding protocol (immediate revocation of all access on last day); anonymous reporting hotline; regular access reviews; DLP tool deployment; and disciplinary consequences for violations.
---
### Scenario β Quick Response Exercise (Phishing Email)
**Q1: Type of attack**
This is a **phishing attack** using **urgency and impersonation** as social engineering techniques β specifically **spear phishing** (targeting a university user population).
**Q2: Three red flags**
1. Creates artificial urgency ("suspended in 24 hours") to bypass rational thinking
2. Requests you to click a link rather than directing you to the official portal via your browser
3. The sender email likely does not match the university's official domain (e.g., @university-support.net vs. @university.edu)
**Q3: Step-by-step response plan**
1. Do **not** click the link
2. Do **not** enter any credentials
3. Check the sender's actual email address carefully
4. Navigate directly to the university portal via a known URL (not the link in the email)
5. Forward the email to the university IT/security team
6. Delete the email
**Q4: Reporting to protect others**
- Report to the university IT helpdesk with the original email attached
- Post a warning (through official channels) to fellow students
- If you clicked the link, immediately change your password and enable MFA
---
## π WEEK 11 β Professionalism in Teamwork
---
### Case Study 3 β The Failing Final-Year Project Team
**Q1: Tuckman's Stages mapping**
| Member | Behavior | Tuckman's Stage |
|---|---|---|
| Ali | Assumed leadership unilaterally | Stuck in Forming/Storming |
| Sara & James | Missed meetings; disengaged | Storming |
| Fatima | Overworking, resentful | Storming |
| Usman | Raised concerns but ignored | Early Norming attempt, regressed |
**Q2: Four absent group skills**
1. **Active listening** β Usman's concerns were dismissed
2. **Role negotiation** β Ali assumed leadership without consensus
3. **Conflict resolution** β disagreements were suppressed rather than addressed
4. **Accountability** β Sara and James faced no consequences for absenteeism
**Q3: Strategies from Week 1**
- Hold a kick-off meeting to collectively assign roles
- Draft a team charter with expectations, communication norms, and deadlines
- Agree on a conflict resolution process upfront
- Establish regular check-ins with documented minutes
**Q4: Risks of default leadership**
Ali's unilateral assumption of leadership risks resentment, lack of buy-in, and poor decision-making due to the absence of diverse input. Leadership should have been discussed openly, perhaps rotating or voted upon, with clearly defined scope and authority.
**Q5: Recovery plan (two weeks remaining)**
1. **Emergency mediation session** β neutral facilitation (e.g., lecturer or peer mediator)
2. **Honest task audit** β list what is done, what remains, and who has capacity
3. **Redistribute tasks** by availability and skill β Fatima should not carry all coding
4. **Daily micro-check-ins** (15 minutes) via a shared group chat
5. **Formal commitment agreement** β each member signs off on their deliverables
6. **Escalate to supervisor** if any member remains unresponsive
---
### Case Study 4 β Conflict in the Agile Development Team
**Q1: Communication failures**
- Senior developers dominated and silenced others
- The scrum master lacked authority to manage conflict
- No safe space for junior members to contribute
- Absence of structured retrospectives to surface issues early
**Q2: How the scrum master should have handled the conflict**
- Invoke a structured conflict protocol β separate the technical disagreement from personal dynamics
- Use **decision frameworks** (e.g., DACI or dot-voting) to resolve architecture disputes objectively
- Escalate to a manager or principal architect if deadlocked
- Hold a private one-to-one with Raza and Chen before the next sprint
**Q3: Why junior members went silent**
This reflects **psychological safety** failure β a concept from Amy Edmondson's research. Junior members feared embarrassment, ridicule, or career consequences from disagreeing with senior colleagues. **Groupthink** and **authority gradient** suppressed their participation.
**Q4: Team Charter for this team**
- **Ground rules:** All voices are heard; no interrupting; critique ideas, not people
- **Communication norms:** Sprint updates via Slack by EOD; architecture decisions documented in Confluence; retrospectives every two weeks
- **Conflict resolution:** Disagreements escalated to scrum master; if unresolved, technical lead arbitrates within 24 hours
- **Decision-making:** Dot-voting for feature prioritization; senior devs do not veto without documented rationale
---
### Scenario β Team Building Exercise
**Team Charter (sample):**
- **Roles:** Project Lead (rotating), Developers, QA, Documenter
- **Communication:** WhatsApp group + weekly 1-hour meeting (Tuesdays, 6 PM)
- **Decision-making:** Majority vote; deadlocks resolved by project lead
- **Conflict resolution:** Private conversation first β team discussion β escalate to lecturer
**Icebreaker (30-minute session):**
- *Two Truths and a Lie* (10 min) β builds familiarity quickly
- *Skill Map* activity (10 min) β each member lists top 2 technical skills; helps identify roles
- *Project brainstorm* (10 min) β generates early ownership and enthusiasm
**Non-responsive member (Week 2):**
1. Private message first β check for personal circumstances
2. If no response within 24 hrs, raise in team meeting
3. Redistribute immediate tasks to avoid project delay
4. Document all attempts to contact
5. Formally inform the lecturer if non-responsiveness continues beyond 48 hours
---
## π WEEK 12 β Professionalism in Social Media
---
### Case Study 5 β The LinkedIn Post That Derailed a Career
**Q1: LinkedIn policies violated**
- **Professional Community Policies:** No harassment, no sharing confidential interview information
- **Content standards:** Professional tone required; personal attacks are prohibited
- Sharing confidential interview questions may also violate **NDAs** or implied confidentiality
**Q2: Consequences**
- **Short-term:** Three job offers withdrawn; reputational damage in local tech community; university tagged negatively
- **Long-term:** Posts are indexed and searchable; future employers will find it; difficulty rebuilding professional credibility; potential legal exposure if defamation is involved
**Q3: Professional alternative post**
> *"Recently went through an interview experience that was challenging and, frankly, disappointing. Rather than dwelling on it, I'm using it as motivation to keep building my skills and presenting my best self. If anyone has advice on navigating tough technical interviews, I'd love to hear it. Onwards and upwards. πͺ"*
**Q4: Personal branding lessons**
LinkedIn is a permanent, professional portfolio β not a private diary. Content strategy should reflect the professional you want to be perceived as. Emotional posts made in haste can undo years of careful brand-building in minutes. Always apply the *24-hour rule* before posting anything reactive.
**Q5: Advice to Amara before going viral:**
"Delete the post immediately. The short-term satisfaction isn't worth the long-term consequences. If you need to vent, do it privately to a trusted friend β not on a professional platform. Then, after reflecting, consider whether there's a constructive way to share your experience."
---
### Case Study 6 β Hate Speech on Slack
**Q1: Classification**
- **Hate speech:** Content that dehumanizes people based on ethnicity β the posts targeted an ethnic group with negative stereotyping
- **Ethnic proliferation:** Spreading ethnically discriminatory views across a workplace platform
- Both definitions apply here
**Q2: Does free speech protect this?**
No. Free speech protections (especially under the First Amendment in the US) apply to **government restriction** of speech β not employer regulation of workplace communications. Company platforms are private, and employees are bound by employment contracts and workplace conduct policies. Discriminatory speech in the workplace exposes the company to **liability under employment law** (e.g., hostile work environment claims).
**Q3: Company's legal and ethical obligations**
- Conduct a prompt, impartial HR investigation
- Preserve records of the offending messages
- Protect the complainant from retaliation
- Take proportionate disciplinary action (up to termination)
- Consult legal counsel to assess liability exposure
- Communicate outcome (within confidentiality limits) to the team
**Q4: Social Media & Communication Policy for a tech company**
Key elements: definition of prohibited content (hate speech, harassment, discrimination); scope (all company-owned platforms including Slack, email, Teams); reporting mechanism (anonymous option); disciplinary consequences; training requirements (annual); bystander responsibility clause
**Q5: Addressing bystanders who liked the posts**
Bystanders who liked and shared the messages are not neutral β their engagement amplified harmful content. They should receive formal counseling, be required to complete diversity and inclusion training, and be warned that future conduct will be monitored. Liking is an act of endorsement on company platforms.
---
### Scenario β Building Your Professional Online Profile
**Sample LinkedIn 'About' Section:**
> "Final-year Computer Science student at [University], specializing in cybersecurity and software development. I've gained hands-on experience through academic projects and an internship in [field], where I developed skills in Python, secure coding, and agile methodologies. I'm passionate about building technology that is both functional and responsible. Currently seeking graduate roles in software engineering or IT security where I can contribute, grow, and solve real-world problems. Open to opportunities β let's connect."
**Three things to remove from personal social media:**
1. Posts with unprofessional language or offensive humor β signals poor judgment
2. Photos from parties showing alcohol or inappropriate behavior β misrepresents your professionalism
3. Political rants or heated arguments in comment threads β raises red flags for team fit
**Refusing to post fake reviews (professional response):**
> "I appreciate you thinking of me, but I can't post fake reviews β it's dishonest to consumers, violates the platform's terms of service, and could expose both of us to legal consequences. I'd genuinely love to support your business: I'm happy to share your page with my network or leave an honest review if I use your service."
---
## π WEEK 13 β Quality Management Process
---
### Case Study 7 β The Bug That Crashed a Banking App
**Q1: Three quality management failures**
1. **Skipped User Acceptance Testing (UAT)** β no real-world user validation before launch
2. **No integration testing** β the balance module and display layer were never tested together
3. **No dedicated QA resource** β quality was treated as optional, not integral to the process
**Q2: QA vs. QC β what was missing?**
- **Quality Assurance (QA):** Process-oriented; ensures the right processes are followed during development (e.g., test planning, code reviews, standards compliance) β *this was missing*
- **Quality Control (QC):** Product-oriented; detects defects in the final product (e.g., testing)
- NovaPay lacked **both**, but QA was the deeper failure β without QA processes, QC (testing) was inevitably skipped under deadline pressure
**Q3: SDLC stage where defect should have been caught**
The integration defect should have been caught during the **Integration Testing phase** β specifically when the balance-calculation module was connected to the display layer. Failing that, **System Testing** or **UAT** would have been the last opportunity before production.
**Q4: Quality Management Plan using PDCA**
- **Plan:** Define quality goals; create a test plan covering unit, integration, system, and UAT; assign a QA engineer
- **Do:** Execute tests at each SDLC stage; log and categorize all defects
- **Check:** Analyze defect density, test coverage, and user feedback post-launch
- **Act:** Retrospect after launch; update processes to prevent recurrence; implement regression testing
**Q5: Recommended quality standards**
- **ISO 9001:** Establishes a quality management system framework β appropriate for NovaPay to demonstrate to regulators that processes are in place
- **CMMI Level 2β3:** Focuses specifically on software process maturity β ideal for a fintech startup to formalize development practices progressively
---
### Case Study 8 β Implementing Quality Culture at DevForge
**Q1: Why teams resist quality processes**
- Seen as adding bureaucracy without visible short-term value
- Developers view testing/documentation as slowing down delivery
- Past "quality initiatives" may have failed, creating cynicism
- Fear of having work scrutinized and defects attributed personally
**Q2: Three activities in the first 30 days**
1. **Conduct a quality audit** β identify the biggest recurring defect patterns and missed deadlines; use data, not opinion
2. **Quick wins** β fix one visible, painful problem immediately (e.g., automate a manual test) to build credibility with developers
3. **Workshops not mandates** β run collaborative sessions where developers co-design the new processes; ownership drives adoption
**Q3: PDCA applied to DevForge**
- **Plan:** Identify root causes of client losses; define target metrics (defect rate, on-time delivery)
- **Do:** Roll out new test standards, code review protocols, and sprint retrospectives
- **Check:** Monthly review of defect rate, sprint velocity, and client satisfaction scores
- **Act:** Refine processes based on data; celebrate improvements publicly
**Q4: Success metrics after six months**
- Defect escape rate (bugs found post-deployment) reduced by β₯50%
- On-time delivery rate increased to β₯85%
- Developer satisfaction with quality processes (internal survey)
- Reduction in rework hours per sprint
- Zero client escalations related to recurring bugs
**Q5: Internal Memo (QA Director to Development Team)**
> *To: Development Team | From: QA Director | Re: Our Quality Journey*
>
> *I want to be direct: the new quality processes are not here to slow you down or question your skills β they're here because our clients and our reputation depend on us. Every bug that reaches a client is time we spend firefighting instead of building. Our goal is to catch issues early, when they're cheap to fix, rather than late, when they cost us contracts.*
>
> *I need your expertise to make this work. You know the codebase better than anyone. Over the next month, I'll be listening as much as directing. Let's build something we're all proud to ship.*
---
### Scenario β You Are the QA Lead
**Risk-ranked testing activities (highest to lowest priority):**
1. **Security testing** β a breach on an e-commerce platform is catastrophic (financial and legal liability)
2. **Integration testing** β most production bugs arise at integration points
3. **User acceptance testing** β confirms core business flows work as expected
4. **Performance/load testing** β defer to post-launch with monitoring in place
5. **Unit tests** β defer (assume developers have run basic unit tests during development)
**Risk assessment memo (summary):**
> Reducing testing from four weeks to one means integration defects, security vulnerabilities, and broken checkout flows may reach production. The likely consequence is customer data exposure, failed transactions, and regulatory liability β all of which carry costs far exceeding the cost of a delayed launch. Recommend extending the deadline by two weeks, or deploying to a limited beta audience first.
**Post-launch monitoring plan:**
- Deploy **real-user monitoring (RUM)** and error-logging tools (e.g., Sentry, Datadog)
- Set up automated alerts for error rate spikes, failed transactions, and latency thresholds
- Assign a dedicated on-call engineer for the first two weeks post-launch
- Conduct daily defect triage meetings in week one
- Plan a hotfix sprint in week two to address issues surfaced by monitoring
---
## π WEEK 14 β Intellectual Property
---
### Case Study 9 β The Plagiarised Final-Year Thesis
**Q1: Why Karim's actions constitute plagiarism**
Plagiarism is using someone else's words or ideas without attribution β regardless of comprehension. Karim copied verbatim paragraphs from published works and presented them as his own original analysis. The 64% similarity score confirms the extent. Understanding content does not grant the right to reproduce it without citation.
**Q2: Is Karim's defense valid?**
No. The defence fails on two grounds:
- **Legally:** Copyright is violated by reproduction, not by misunderstanding
- **Academically:** Universities define plagiarism by outcome (uncited reproduction), not intent. Ignorance of the rule is explicitly not a defence under most academic integrity policies
**Q3: Spectrum of consequences**
- **Warning + required resubmission** β first-time, minor similarity
- **Grade penalty (fail on submission)** β significant plagiarism, partial original work present
- **Module failure** β widespread copying with clear intent
- **Academic misconduct formal hearing** β 64% similarity warrants this
- **Suspension or expulsion** β repeat offence or if fraud was deliberate
At 64% similarity on a capstone project, a formal hearing with likely module failure is the appropriate starting point.
**Q4: Correctly rewritten paragraph (example)**
*Original (plagiarised):* "The NIST Cybersecurity Framework provides a policy framework of computer security guidance for how private sector organizations in the US can assess and improve their ability to prevent, detect, and respond to cyber attacks."
*Correctly paraphrased with citation:*
The NIST Cybersecurity Framework offers a structured approach for private sector organizations to evaluate and strengthen their defenses against cyber threats, covering prevention, detection, and response capabilities (NIST, 2018).
**Q5: Plagiarism Awareness Card (key content)**
- **What is plagiarism?** Using someone else's words or ideas without credit
- **What counts?** Direct copying, paraphrasing without citation, self-plagiarism, ghost-writing
- **How to avoid it:** Cite every source; paraphrase in your own words; use quotation marks for direct quotes; use a reference manager
- **Consequences:** Fail grade β suspension β expulsion
- **Resources:** Writing Centre, Turnitin self-check, referencing guide on the university portal
---
### Case Study 10 β Reverse Engineering the Competitor's App
**Q1: Definition and legal boundary**
Reverse engineering is the process of analyzing a compiled product to understand its design, architecture, or source code. It becomes **illegal** when it violates the software's license agreement (most EULAs prohibit decompilation), breaches copyright law by reproducing protected code, or is used to create a competing product from the recovered source β as QuickTech did.
**Q2: Legal remedies for BrightSoft**
- **Copyright infringement claim** β reproducing protected source code violates the Copyright Act
- **Breach of license agreement** β the commercial license explicitly prohibits decompilation
- **Trade secrets misappropriation** β if source code qualifies as a trade secret
- Remedies: injunction to stop QuickTech selling the product; damages (lost revenue); legal fees
**Q3: Ethical conditions for reverse engineering**
It is ethically justifiable when: (a) it is necessary for **interoperability** (connecting systems that don't share standards), (b) it is for **security research** to identify and responsibly disclose vulnerabilities, or (c) no other means of achieving the goal exists. It is not ethical when the purpose is commercial exploitation of another's work.
**Q4: Legitimate use case**
A healthcare company reverse-engineering a legacy medical device's communication protocol (no longer supported by its manufacturer) to integrate it with a modern EHR system β for patient safety, not profit.
---
### Case Study 11 β TechNova Cybersquatting
**Q1: Does this meet the ACPA requirements?**
- **Distinctive or famous mark:** TechNova Solutions is a registered trademark β
- **Confusingly similar domain:** technova.com, technovasolutions.com mirror the trademark exactly β
- **Bad-faith intent to profit:** Registrant emailed offering to sell for $80,000 immediately after the press release β
**β Yes, this clearly meets all three ACPA requirements.**
**Q2: Evidence of bad-faith intent**
- Timing: registered within 24 hours of a public rebrand announcement
- The demand email constitutes direct evidence of intent to profit
- Registrant has no prior legitimate association with the "TechNova" brand
- Multiple variations registered simultaneously β a pattern consistent with cybersquatting
**Q3: UDRP as alternative to litigation**
The Uniform Domain-Name Dispute-Resolution Policy (administered by ICANN) allows trademark holders to file a complaint to have domain names transferred or cancelled without going to court. It is faster (typically resolved within 60 days), cheaper, and global in scope β making it the preferred first step over litigation.
**Q4: Recommended course of action**
1. File a **UDRP complaint** immediately (fastest path to domain recovery)
2. Do **not** pay the $80,000 β this rewards bad-faith behavior and may invite further demands
3. Simultaneously send a **cease-and-desist letter** to the registrant
4. Document all evidence (registration timestamps, demand email) for potential ACPA litigation if UDRP fails
**Q5: Domain protection strategy for a startup**
- Register your primary domain **before** any public announcement
- Register common variations: .com, .net, .org, country-code TLDs relevant to your market
- Register common misspellings
- Set up **domain monitoring alerts** through a registrar or trademark watch service
- File a trademark application early β it strengthens all future IP claims
---
### Case Study 12 β Open Source and the Hidden GPL License
**Q1: GPL vs. permissive licenses**
- **GPL (GNU General Public License):** Copyleft license β any derivative work must also be released under GPL (open source). You cannot incorporate GPL code into a proprietary product without open-sourcing your entire product.
- **MIT/Apache 2.0:** Permissive licenses β you may use, modify, and distribute the code in commercial/proprietary products with minimal restrictions (attribution required; Apache 2.0 also includes a patent grant)
**Q2: ZenSoft's options**
- **Replace the GPL library** with an MIT/Apache-licensed equivalent β the cleanest resolution
- **Negotiate a commercial license** with the library maintainer (some GPL projects offer dual licensing)
- **Open-source the product** β comply with the GPL fully, but this eliminates the closed-source commercial advantage
- Continuing without action risks injunctions, reputational damage, and forced open-sourcing by a court
**Q3: Due-diligence process before using open source**
1. Audit all dependencies using a **Software Composition Analysis (SCA)** tool (e.g., Black Duck, FOSSA)
2. Maintain a **bill of materials (SBOM)** listing every library and its license
3. Establish an internal policy classifying acceptable licenses by use case (e.g., MIT/Apache = OK for commercial; GPL = prohibited in closed products)
4. Review licenses at every sprint/release cycle, not just at project start
**Q4: Why developers contribute to open source without payment**
- **Reputation and portfolio building** β open source contributions are publicly visible on GitHub and valued by employers
- **Intrinsic motivation** β desire to solve problems and improve tools they themselves use
- **Community and belonging** β participation in respected projects brings recognition and peer validation
---
## π Integrated Scenario β Zara's IP Dilemma ("Focuz")
**Priority ranking of IP issues:**
| Rank | Issue | Why It's Urgent |
|---|---|---|
| 1 | **Trademark conflict with "Focus Flow"** | Risk of injunction that forces the app offline β kills the business immediately |
| 2 | **Freelancer IP ownership** | If contracts didn't assign IP, Zara may not legally own her own app |
| 3 | **Open source license compliance** | GPL violation could force the app open-source or result in legal action |
| 4 | **Domain registration** | Cybersquatters will act fast β register now before others do |
| 5 | **Competitive intelligence on Focus Flow** | Important, but no immediate legal risk β gather this while addressing the others |
**Freelancer IP assignment clause:**
> "All work product, inventions, code, designs, and deliverables created by the Contractor in connection with this engagement shall be considered works made for hire and shall be the exclusive property of [Zara/Company]. To the extent any work product does not qualify as a work made for hire, the Contractor hereby irrevocably assigns all right, title, and interest, including all intellectual property rights, to [Company]."
**Advise Zara: rename or fight?**
Rename. "Focuz" is phonetically identical to "Focus Flow" and operates in the same app category. Fighting a trademark similarity claim is expensive, time-consuming, and uncertain β and the press attention during a legal dispute would overshadow the positive launch coverage. Rebranding now, while the app is young, is far less costly than litigating later.
**Legal competitive intelligence on Focus Flow:**
- Review their **App Store/Play Store listings** β public information
- Read their **privacy policy and terms of service** β publicly available
- Analyze **publicly available reviews and user feedback**
- Monitor their **social media and press releases**
- Search **patent and trademark databases** for their registered IP
- *Never:* decompile their app, access their systems, or use information obtained through deception
---
This covers solutions for all 12 case studies, all weekly scenarios, and the integrated IP scenario. Let me know if you'd like any solution expanded, formatted into a Word document, or adapted for a specific assessment format.