DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This action is in response to claim amendments and remarks filed by Applicant’s representative on July 21, 2025. Claims 1-20 are pending, no claims have been canceled, and no new claims have been added.
Response to Amendments and Remarks
Applicant’s latest filed claim amendments and corresponding remarks dated July 21, 2025 have been fully considered. Applicant’s remarks and/or comments are generally directed to the current claim amendment(s), and accordingly deemed moot in light of the new grounds of rejection provided with this action.
With regards to Applicant’s latest amendments and remarks, Applicant firstly notes and remarks that the independent claim(s), and particularly independent claim 1, has been further amended to now expressly recite
“A method for automating connection to a collaborative software platform, the method comprising:
establishing, by a computing device, a connection with a display device;
receiving roster data associated with at least one moderator identifier and comprising a plurality of participant identifiers, the at least one moderator identifier comprising a first moderator identifier;
receiving a first request to access the roster data from a moderator device, the first request comprising a second moderator identifier corresponding to the moderator device;
permitting the moderator device access to the roster data based on the first moderator identifier being the same as the second moderator identifier;
receiving, from the moderator device, a second request to start a collaboration session on the collaborative software platform and a session key corresponding to the collaboration session, the session key generated by the moderator device;
receiving a third request from a participant device to join the collaboration session, the third request corresponding to a first participant identifier and including the session key;
determining the first participant identifier corresponds to the plurality of participant identifiers in the roster data;
causing the participant device corresponding to the set of participant identifier to connect to the collaboration session using the session key; and
causing the participant device to display media content corresponding to the collaboration session on a respective participant device, wherein the display device and the moderator device are connected to the collaboration session and each display the media content corresponding to the collaboration session
With respect to the above, Applicant notes and remarks that none of the prior art reference(s) applied in rejecting independent claim 1 [Vu et al, Johansson et al], either individually or in combination, expressly and properly discloses or suggests the above amended claim feature(s) or limitation(s) as currently recited by amended independent claim 1 above (and similarly in independent claim 11). In particular, Applicant states or remarks that neither prior art of record properly teaches at least the feature of “receiving, from the moderator device, a second request to start a collaboration session on the collaborative software platform and a session key corresponding to the collaboration session, the session key generated by the moderator device; and receiving a third request from a participant device to join the collaboration session, the third request corresponding to a first participant identifier and including the session key….” [Applicant Remarks: par 4, pg. 9 – par 2, pg. 10].
However, in response to Applicant’s amended feature and associated remarks, the Office asserts and notes that the newly amended feature(s) are now expressly taught or disclosed in view of teachings and/or disclosures by at least Johansson and Geng et al, as discussed / cited in a new ground of rejection included with this action.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103(a) 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.
Claim(s) 1-20 is/are rejected under 35 U.S.C. 103 as being disclosed by Vu et al (hereinafter Vu), US Patent Publication 20170195374 A1 (publication date July 2017) in view of Johansson et al (hereinafter Johansson ‘766), US Patent 10616278 B1 (publication date April 2020) and in further view of Geng et al (hereinafter Geng), Foreign Patent Pub CN118972083 A (publication date June 2023)
As per claim{s} 1, 11, Vu discloses substantial features of the invention as above, including the recited feature of a method for automating connection to a collaborative software platform, the method comprising:
establishing, by a computing device (Vu: e.g., Moderator Client Device_120 ) [0030, Fig. 1], a connection with a display device (Vu: e.g., Display Device_105, which is coupled to and/or controlled by Receiver_110) [0030, 0033, Fig. 1] (e.g., Methods and products for ‘connecting a device to an external display’ are well known in the art. For example, a laptop computer may be connected to a television display using a wired connection such as a High-Definition Multimedia Interface (HDMI) cable. Using the HDMI cable, ‘a single laptop device may connect to a television’ and mirror content on the laptop display to the television screen) [0004] (e.g., There are many instances in which a computer user may wish to share the display of his or her computer screen with others. For example, in connection with a presentation being given at a business meeting, a speaker may desire to display information to an audience, a teacher may wish to show a classroom of students a ‘computer display’, etc.) [0029] (e.g., In the embodiment of FIG. 1, Moderator client device 120 and member client devices 130 interact through local network 115 to send content to Receiver 110. Receiver 110 receives ‘communications’ from Moderator client device 120, and responsive to those communications, causes the content of one or more of member client devices 130 to be displayed on Display 105. Display 105 may be any suitable display and provides an interface for presenting information received from receiver 110 to external systems, users, or memory. Display 105 may be a ‘television screen’, a ‘computer monitor’ or a ‘projector’ and also may include an interface to a printer or a speaker, etc.) [0032] (e.g., First, moderator client device 120 searches local network 115 for receiver 110. After locating the receiver, Moderator client device 120 establishes a connection to Receiver 110 {and Display 105 that it is coupled to} and transmits a request to begin a ‘session’) [0061; Fig. 4];
receiving roster data associated with at least one moderator identifier and comprising a plurality of participant identifiers (Vu: e.g., as it may be desirable for the Moderator to know which ‘member client devices are participating’ in a session, ‘Ms. Wormwood’ {Moderator / teacher} may request, via ‘message’ 725, a ‘list of members’ {Member List / Roster} that have joined the ‘session’. In response to receiving message 725, Receiver 110 transmits to the requestor, Ms. Wormwood, the ‘list of clients’ {Member List / Roster} that have joined the session in message 730. The ‘list of clients’ may include the ‘Session IDs of the clients’) [0074, Fig. 7], the at least one moderator identifier comprising a first moderator identifier (Vu: e.g., A ‘client device’ may be ‘identified’ as the ‘Moderator’ Client device 120 by making that selection when signing into or syncing with the content sharing system. Alternatively, the ‘client device’ that begins or creates the content sharing session may be ‘identified’ as the ‘Moderator’ Client device 120. In yet another example, the receiver may incorporate a calendaring system facilitating the scheduling of meetings between clients. When a member client schedules a meeting appointment using the content sharing system the device of the ‘client’ that made the meeting appointment may be elected as the ‘moderator’ client device 120 by default. All clients that are not the moderator client will be deemed ‘member’ clients ) [0031, Fig. 1];
receiving a first request to access the roster data from a moderator device (Vu: e.g., as it may be desirable for the Moderator to know which ‘member client devices are participating’ in a session, ‘Ms. Wormwood’ {Moderator / teacher} may ‘request’, via ‘message’ 725, a ‘list of members’ {Member List / Roster} that have joined the ‘session’. In response to receiving message 725, Receiver 110 transmits to the requestor, Ms. Wormwood, the ‘list of clients’ {Member List / Roster} that have joined the session in message 730. The ‘list of clients’ may include the ‘Session IDs of the clients’) [0074, Fig. 7], the first request comprising a second moderator identifier corresponding to the moderator device (Vu: e.g., A ‘client device’ may be ‘identified’ as the ‘Moderator’ Client device 120 by making that selection when signing into or syncing with the content sharing system. Alternatively, the ‘client device’ that begins or creates the content sharing session ‘may be identified as the Moderator Client device 120’. In yet another example, the receiver may incorporate a calendaring system facilitating the scheduling of meetings between clients. When a member client schedules a meeting appointment using the content sharing system the device of the ‘client’ that made the meeting appointment may be elected as the ‘moderator’ client device 120 by default. All clients that are not the moderator client will be deemed ‘member’ clients ) [0031, Fig. 1] (e.g., For example, a file within the ShareCast application may include a list of ‘MAC addresses’ that is consulted to determine whether a ‘specific client’ may serve as ‘Moderator’ client device 120) [0062] (e.g., ‘Session IDs’ may be used to identify the clients of the session {i.e., Moderator client and/or non-moderator / member clients) [0074, Fig. 7];
permitting the moderator device access to the roster data based on the first moderator identifier being the same as the second moderator identifier (Vu: e.g., as it may be desirable for the Moderator to know which ‘member client devices are participating’ in a session, ‘Ms. Wormwood’ {Moderator / teacher} may ‘request’, via ‘message’ 725, a ‘list of members’ {Member List / Roster} that have joined the ‘session’. In response to receiving message 725, Receiver 110 transmits to the requestor, Ms. Wormwood, the ‘list of clients’ {Member List / Roster} that have joined the session in message 730. The ‘list of clients’ may include the ‘Session IDs of the clients’) [0074, Fig. 7] (Vu: e.g., A ‘client device’ may be ‘identified’ as the ‘Moderator’ Client device 120 by making that selection when ‘signing into’ or syncing with the Content sharing system. Alternatively, the ‘client device’ that begins or creates the content sharing session ‘may be identified as the Moderator Client device 120’) [0031, Fig. 1] (e.g., For example, a file within the ShareCast application may include a list of ‘MAC addresses’ that is consulted to determine whether a ‘specific client’ may serve as ‘Moderator’ client device 120) [0062];
receiving, from the moderator device, a second request to start a collaboration session on the collaborative software platform (Vu: e.g., At step 405, the request to begin a ‘session’ is received by Receiver 110 from Moderator client device 120. In a preferred embodiment, only a client device that is authorized to become a ‘moderator’ client may serve as ‘Moderator’ client device 120. In alternative embodiments, whichever client device that first requests to initiate a session may be designated as ‘moderator’ client device 120...At step 410, a request from a member client device to join the session is received by receiver 110. In embodiments in which ‘Member’ Client devices 130 cannot initiate a session, the request {to allow ‘member’ clients} to ‘join’ the session may be sent to Receiver 110 by Moderator client device 120. Preferably, Receiver 110 does not initiate a ‘session’ until a ‘Moderator client device’ requests ‘to initiate or join a session’...{member} Clients that ‘join’ the session may use a WebSocket protocol to connect to Receiver 110, to provide a full-duplex communication channel over a TCP connection, although any other suitable protocol may be used. At step 415, an event notification request is received. Moderator client device 120 may request to be notified of any suitable event, such as a new member client ‘joining’ or leaving the session ) [0060-0065, Fig. 4];
determining the first participant identifier corresponds to the plurality of participant identifiers in the roster data (Vu: e.g., A ‘client device’ may be ‘identified’ as the ‘Moderator’ Client device 120 by making that selection when signing into or syncing with the content sharing system. Alternatively, the ‘client device’ that begins or creates the content sharing session ‘may be identified as the Moderator Client device 120’. In yet another example, the receiver may incorporate a calendaring system facilitating the scheduling of meetings between clients. When a member client schedules a meeting appointment using the content sharing system the device of the ‘client’ that made the meeting appointment may be elected as the ‘moderator’ client device 120 by default. All clients that are not the moderator client will be deemed ‘member’ clients ) [0031, Fig. 1];
causing the participant device corresponding to the participant identifier to connect to the collaboration session (Vu: e.g., …{member} Clients that ‘join’ the session may use a WebSocket protocol to ‘connect’ to Receiver 110, to provide a full-duplex communication channel over a TCP connection, although any other suitable protocol may be used…Moderator client device 120 may request to be ‘notified’ of any suitable event, such as a new member client ‘joining’ {or leaving} the session ) [0060-0065, Fig. 4] (e.g., Next, student “Susie” transmits message 715 to Receiver 110 requesting to ‘join’ the content sharing session. Message 715 may indicate that it was transmitted from a member client device, and that the requestor's ‘session ID’ is “Susie.” In an embodiment in which Receiver 110 handles multiple content sharing sessions simultaneously, message 715 also may indicate which ‘session’ client member device 130 is requesting to join. In response to receipt of message 715, Receiver 110 transmits message 720 to Susie acknowledging that message 715 was received and that Suzie's member client device 130 has been ‘added’ to the ‘session’) [0073, Figs. 5 & 7]; and
causing the participant device to display media content corresponding to the collaboration session on a respective participant device, wherein the display device and the moderator device are connected to the collaboration session and each display the media content corresponding to the collaboration session (Vu: e.g., For example, a ‘teacher’ using ‘Moderator’ client device_120 deemed a ‘presenting’ client device may grant a student ‘access’ to control moderator client device 120 via the student's member client device 130. ‘Screen’ 1110 of Moderator client device 120 may be displayed on screen 1120 of ‘Member’ Client device{s} 130, the ‘screen of Display 105’, or ‘both’. ) [0083, Fig. 11].
But while Vu discloses substantial features of the invention above, he does not expressly disclose the additional recited features of receiving, from the moderator device, a second request to connect a set of participant devices corresponding to a set of participant identifiers to a collaboration session on the collaborative software platform ‘and a session key corresponding to the collaboration sessionand causing each participant device of the set of participant devices corresponding to the set of participant identifiers to connect to the collaboration session ‘using the session key’.
However, in a related endeavor, Johansson particularly discloses the additional recited features of the additional recited features of receiving, from the moderator device, a second request to connect a set of participant devices corresponding to a set of participant identifiers to a collaboration session on the collaborative software platform ‘and a session key corresponding to the collaboration sessionand causing each participant device of the set of participant devices corresponding to the set of participant identifiers to connect to the collaboration session ‘using the session key’ (Johansson: e.g., FIG. 6 shows an illustrative example of an environment in which a participant utilizes a ‘one-time password (OTP) token’ {session key} to enable authentication of the participant and participation in a virtual meeting in accordance with at least one embodiment) [col 1, L57-61] (e.g., As noted above, in order for a ‘participant’ to join a virtual meeting, he/she may be required to transmit an SMS message or other electronic message that includes a ‘one-time password’ {OTP} to a messaging service or directly to the Virtual Meeting Service, which may utilize the one-time password to authenticate the participant. Accordingly, FIG. 6 shows an illustrative example of an environment 600 in which a participant utilizes a ‘One-time Password (OTP) Token’ {session key} to enable ‘authentication’ of the Participant 602 and ‘participation’ {joining in} in a virtual meeting in accordance with at least one embodiment. In the environment 600, a Participant 602 of a particular virtual meeting transmits a ‘request’ to the Virtual meeting service 608 ‘to join the virtual meeting’. For instance, the Participant 602, through a computing device, may invoke a ‘link’, which may cause his/her computing device to transmit a ‘unique participant identifier’ to the virtual meeting service 608. This identifier may be utilized to identify the target virtual meeting that the participant 602 wishes to join, as well as any applicable policies generated by the moderator of the virtual meeting….In an embodiment, when the Virtual meeting service 608 receives the Participant's 602 ‘request to join the meeting’, the Virtual meeting service 608 prompts the Particip’ant 602, through his/her computing device, to transmit an SMS message to a messaging service 606 that includes a ‘one-time password’ from an ‘OTP token 604’ issued to the Participant 602 by the Virtual meeting service 608 or other Authorized entity. The Virtual meeting service 608 may associate this provided OTP token 604 with a ‘Participant Identifier’, which may also be provided within the SMS message to the messaging service 606. The OTP token 604 may be synchronized with a common seed such that the virtual meeting service 608 may determine the expected one-time password for the participant 602…When the Messaging service 606 receives the SMS message from the participant 602, the Messaging service 606 may identify a phone number, e-mail address or other contact information for the participant 602 from the SMS message. Further, the Messaging service 606 may ‘parse the SMS message’ to obtain the ‘Participants 602 Identifier’, the ‘one-time password’ from the ‘OTP token 604’ {session key}, and ‘other information’ that may be included within the SMS message as desired (e.g., ‘Virtual meeting identifier’, etc.). The Messaging service 606 may transmit this information to the Virtual meeting service 608, which may process the provided information “to determine whether the participant 602 may join the requested virtual meeting”…The OTP service may subsequently utilize this one-time password seed to obtain an expected ‘one-time password’, which may be utilized to determine whether the provided one-time password from the Participant 602 produces a ‘match’ with this expected one-time password. If so, then the Participant 602 may be ‘authenticated’. The OTP service may transmit a notification to the virtual meeting service 608 indicating whether the Participant 602 has been ‘authenticated’ or not, and if the Participant 602 has been ‘authenticated’, the Virtual Meeting Service 608 may utilize the other provided information to identify a contact method for enabling the participant 602 to join the virtual meeting) [Abstract, col 13, L65 – col 15, L5; Figs. 6, 8 & 10].
It would thus be obvious to one of ordinary skill in the art before the effective date of the invention to modify and/or combine Vu’s invention with the above said additional feature, as expressly disclosed by Johansson, for the motivation of providing a method and system for receiving and processing a request from a customer {moderator} to allow specified participants to join in or participate in a virtual meeting, and enabling the participants to securely join the virtual meeting or conference [Johansson: Abstract, col 2, L30-52; Fig. 6].
Further, while the combination of Vu and Johansson discloses substantial features of the invention above, they do not expressly disclose the additional recited feature of wherein ‘the session key is generated by the moderator device’.
However, in a related endeavor, Geng particularly discloses the additional recited features of the additional recited feature of wherein ‘the session key is generated by the moderator device’ (Geng: e.g., In the traditional online conference scene, the conference is usually created by the Conference Moderator, and the generated ‘Conference Link and Key’ are sent to the person (Conferee) who needs to ‘participate’ in the conference. The ‘Conference Link and the Key’ can be used {by the Conferee} for entering {joining / accessing} the conference… Based on this, a conference access scheme based on identity authentication is proposed in the related art, for example, an End to End Encryption (E2EE)-based conference access scheme. In the E2EE-based conference access solution, the Conference Presider {Moderator} randomly generates a ‘conference Security Key’ {session key}, and the Conference presider and each conferee perform identity authentication, and sends the cryptograph of the ‘conference security key’ to the ‘Conferee’ passing the identity authentication through E2EE technology, and the cryptograph of the conference security key can be decrypted only by the corresponding conferee) [pg. 2, par 3-4].
It would thus be obvious to one of ordinary skill in the art before the effective date of the invention to modify the combination with the above said additional feature, as expressly disclosed by Geng, for the motivation of providing a conference access method which can ensure security by allowing the external conferee to access the conference through identity verification in a cross-domain scene [Geng: Abstract, pg. 2, par 6; Figs. 1 & 7].
As per claim{s} 2, 12, Vu in view of Johansson, and Vu in particular, discloses the recited feature of the method further comprising wherein the plurality of participant identifiers correspond to a set of participant devices, the method further permitting the moderator device moderator access to the collaboration session; and permitting each participant device of the set of participant devices access to the collaboration session, the participant access granting, relative to the moderator access, restricted control of the collaboration session, wherein displaying the media content on the display device is based at least in part on the moderator access and the participant access (Vu: e.g., At step 405, the request to begin a session is received by receiver 110 from moderator client device 120. In a preferred embodiment, only a client device that is authorized to become a moderator client may serve as moderator client device 120. In alternative embodiments, whichever client device that first requests to initiate a session may be designated as moderator client device 120. For example, a file within the ShareCast application may include a list of MAC addresses that is ‘consulted’ to determine whether a specific client may serve as ‘moderator’ client device 120) [0062, Fig. 4] (e.g., At step 410, a request from a member client device to join the session is received by Receiver 110…Preferably, Receiver 110 does not initiate a session until a moderator client device requests to initiate or join a session. Alternatively, if a member client device requests to initiate a session, Receiver 110 may create a ‘limited-access session’ until Moderator client device 120 joins the session. For example, in a ‘limited-access session’, the Receiver may allow Member client devices 130 to join the session, but ‘may not transmit content’ from member client devices 130 to Display 105 ‘until authorized by a Moderator Client device’ to do so) [0063; Fig. 4].
As per claim{s} 3, 13, Vu in view of Johansson, and Vu in particular, discloses the recited feature of the method further comprising receiving, from the moderator device, a fourth request to modify at least one restriction associated with the participant access for at least a participant device connected to the collaboration session (Vu: e.g., expressly teaches that a Moderator Client device can transmit a request to ‘promote’ a first one of the plurality of Member Client devices to the Receiver, which then receives and transmits to the Display content from the first one of the plurality of member client devices {authorized / ‘promoted’ to become a ‘presenter’ and share / display content on the Display device}) [Abstract, 0011-0012] [0080, Fig. 9] (e.g., At step 410, a request from a member client device to join the session is received by Receiver 110….Preferably, Receiver 110 does not initiate a session until a moderator client device requests to initiate or join a session. Alternatively, if a member client device requests to initiate a session, Receiver 110 may create a ‘limited-access session’ until Moderator client device 120 joins the session. For example, in a ‘limited-access session’, the receiver may allow Member client devices 130 to join the session, but ‘may not transmit content’ from member client devices 130 to Display 105 ‘until authorized by a Moderator Client device’ to do so) [0063; Fig. 4] (e.g., ‘delegating’ moderator authority / control to a subset of member devices) [Abstract, 0048, 0093; Fig. 14].
As per claim{s} 4, 14, Vu in view of Johansson, and Vu in particular, discloses the recited feature of the method wherein at least a portion of the media content is generated by the first participant device, the method further comprising: causing the moderator device to display the portion of the media content generated by the participant device; and
causing the display device to display the portion of the media content generated by the participant device (Vu: e.g., Referring to FIG. 11, in accordance with another aspect of the present invention, a non-presenting client device may be given control of a presenting client device such that the non-presenting client device may remotely interact with the display of the presenting client device. In this manner, the cursor of the presenting client's device may be remotely controlled by input on the non-presenting client device. For example, a teacher using Moderator client device 120 deemed a ‘presenting client device’ may grant a student ‘access’ to Control moderator client device 120 via the Student's Member client device 130. Screen 1110 of Moderator client device 120 may be displayed on Screen 1120 of Member client device 130, the ‘Screen of Display 105’, or ‘both’ . The student may use stylus 1130, or any other input device, to input information or content onto moderator client device 120. The receiver may also be coupled with motion recognition software and hardware allowing for input by simply gesturing. The ‘input’ from Member client device 130 may ‘appear’ on Screen 1110 of teacher's Member client device 120, on Display 105, or on ‘both’ Screen 1110 and Display 105. The input from the non-presenting client, such as mouse movements and/or keystrokes, may be recorded for later review and deletion. This arrangement may be particularly desirable where the Teacher selects one student to answer a problem and ‘displays to the whole class’ that Student's approach to answering the problem) [0083; Fig. 11].
As per claim{s} 5, 15, Vu in view of Johansson discloses the recited feature of the method further comprising
receiving, from the moderator device, a fourth request to connect one or more additional participant devices to the collaboration session, the one or more additional participant devices not corresponding to the roster data (Vu: e.g., Alternatively, Ms. Wormwood may request receiver 110 to send Moderator client device 120 a ‘notification’ when a ‘new member client device’ {requests to} join / ‘joins’ a session. In this case, Ms. Wormwood may transmit message 735 to Receiver 110, including a request to ‘notify’ moderator client device 120 of new member client devices 130 that join the session. The ShareCast server running on receiver 110 maintains a database of the clients ‘connected’ to the ShareCast server for each session. Additionally, any of the clients may query the database and receive the ‘list of clients’ connected to the ShareCast server (e.g., currently ‘participating’ in the session). In response message 735, the Receiver transmits to Moderator client device 120 Message 740, which acknowledges that Receiver 110 received Message 735. Subsequently, when a new member client device ‘requests to join’ the session via Message 745, the Student's name or ID is transmitted by receiver 110 to Moderator client device 120 {for approval or rejection / denial of the request to join the session}) [0075-0077, Fig. 7];
causing each additional participant device of the one or more additional participant devices to connect to the collaboration session using the session key (Johansson: e.g., FIG. 6 shows an illustrative example of an environment in which a participant utilizes a ‘one-time password (OTP) token’ {session key} to enable authentication of the participant and participation in a virtual meeting in accordance with at least one embodiment) [col 1, L57-61] (e.g., As noted above, in order for a ‘participant’ to join a virtual meeting, he/she may be required to transmit an SMS message or other electronic message that includes a ‘one-time password’ {OTP} to a messaging service or directly to the Virtual Meeting Service, which may utilize the one-time password to authenticate the participant. Accordingly, FIG. 6 shows an illustrative example of an environment 600 in which a participant utilizes a ‘One-time Password (OTP) Token’ {session key} to enable ‘authentication’ of the Participant 602 and ‘participation’ {joining in} in a virtual meeting in accordance with at least one embodiment. In the environment 600, a Participant 602 of a particular virtual meeting transmits a ‘request’ to the Virtual meeting service 608 ‘to join the virtual meeting’. For instance, the Participant 602, through a computing device, may invoke a ‘link’, which may cause his/her computing device to transmit a ‘unique participant identifier’ to the virtual meeting service 608. This identifier may be utilized to identify the target virtual meeting that the participant 602 wishes to join, as well as any applicable policies generated by the moderator of the virtual meeting….In an embodiment, when the Virtual meeting service 608 receives the Participant's 602 ‘request to join the meeting’, the Virtual meeting service 608 prompts the Participant 602, through his/her computing device, to transmit an SMS message to a messaging service 606 that includes a ‘one-time password’ from an ‘OTP token 604’ {session key} issued to the Participant 602 by the Virtual meeting service 608 or other Authorized entity) [Abstract, col 13, L65 – col 15, L5; Figs. 6, 8 & 10]; and
causing each additional participant device of the one or more additional participant devices to display the media content corresponding to the collaboration session (Vu: e.g., Referring to FIG. 11, in accordance with another aspect of the present invention, a non-presenting client device may be given control of a presenting client device such that the non-presenting client device may remotely interact with the display of the presenting client device. In this manner, the cursor of the presenting client's device may be remotely controlled by input on the non-presenting client device. For example, a teacher using Moderator client device 120 deemed a ‘presenting client device’ may grant a student ‘access’ to Control moderator client device 120 via the Student's Member client device 130. Screen 1110 of Moderator client device 120 may be displayed on Screen 1120 of Member client device 130, the ‘Screen of Display 105’, or ‘both’ . The student may use stylus 1130, or any other input device, to input information or content onto moderator client device 120. The receiver may also be coupled with motion recognition software and hardware allowing for input by simply gesturing. The ‘input’ from Member client device 130 may ‘appear’ on Screen 1110 of teacher's Member client device 120, on Display 105, or on ‘both’ Screen 1110 and Display 105. The input from the non-presenting client, such as mouse movements and/or keystrokes, may be recorded for later review and deletion. This arrangement may be particularly desirable where the Teacher selects one student to answer a problem and ‘displays to the whole class’ that Student's approach to answering the problem) [0083; Fig. 11].
As per claim{s} 6, 16, Vu in view of Johansson discloses the recited feature of the method further comprising updating the roster data based on the fourth request to connect the one or more additional participant devices to the collaboration session (Vu: e.g., the ShareCast server running on Receiver 110 ‘maintains’ a database of the clients ‘connected’ to the ShareCast server for each session. Additionally, any of the clients may query the database and receive the ‘list of clients’ connected to the ShareCast server (e.g., currently ‘participating’ in the session). In response message 735) [0075, Fig. 7].
As per claim{s} 7, 17, Vu in view of Johansson discloses the recited feature of the method wherein causing the participant device to connect to the collaboration session using the session key further comprises: transmitting a fifth request to execute a software application installed on the participant device (Vu: e.g. In a preferred embodiment, receiver 110 runs a ‘ShareCast’ protocol configured to control the flow of information between devices. Each of the client devices (e.g., moderator client device 120 and member client devices 130) runs an ‘application’ {SW application} that facilitates communication between the respective client and receiver 110 via the ShareCast protocol) [0055]; and causing the participant device to execute the software application using the session key (Johansson: e.g., FIG. 6 shows an illustrative example of an environment in which a participant utilizes a ‘one-time password (OTP) token’ {session key} to enable authentication of the participant and participation in a virtual meeting in accordance with at least one embodiment) [col 1, L57-61] (e.g., As noted above, in order for a ‘participant’ to join a virtual meeting, he/she may be required to transmit an SMS message or other electronic message that includes a ‘one-time password’ {OTP} to a messaging service or directly to the Virtual Meeting Service, which may utilize the one-time password to authenticate the participant. Accordingly, FIG. 6 shows an illustrative example of an environment 600 in which a participant utilizes a ‘One-time Password (OTP) Token’ {session key} to enable ‘authentication’ of the Participant 602 and ‘participation’ {joining in} in a virtual meeting in accordance with at least one embodiment. In the environment 600, a Participant 602 of a particular virtual meeting transmits a ‘request’ to the Virtual meeting service 608 ‘to join the virtual meeting’. For instance, the Participant 602, through a computing device, may invoke a ‘link’, which may cause his/her computing device to transmit a ‘unique participant identifier’ to the virtual meeting service 608. This identifier may be utilized to identify the target virtual meeting that the participant 602 wishes to join, as well as any applicable policies generated by the moderator of the virtual meeting….In an embodiment, when the Virtual meeting service 608 receives the Participant's 602 ‘request to join the meeting’, the Virtual meeting service 608 prompts the Participant 602, through his/her computing device, to transmit an SMS message to a messaging service 606 that includes a ‘one-time password’ from an ‘OTP token 604’ issued to the Participant 602 by the Virtual meeting service 608 or other Authorized entity. The Virtual meeting service 608 may associate this provided OTP token 604 with a participant identifier, which may also be provided within the SMS message to the messaging service 606. The OTP token 604 may be synchronized with a common seed such that the virtual meeting service 608 may determine the expected one-time password for the participant 602…When the Messaging service 606 receives the SMS message from the participant 602, the Messaging service 606 may identify a phone number, e-mail address or other contact information for the participant 602 from the SMS message. Further, the Messaging service 606 may ‘parse the SMS message’ to obtain the ‘Participants 602 Identifier’, the ‘one-time password’ from the ‘OTP token 604’ {session key}, and ‘other information’ that may be included within the SMS message as desired (e.g., ‘Virtual meeting identifier’, etc.). The Messaging service 606 may transmit this information to the Virtual meeting service 608, which may process the provided information “to determine whether the participant 602 may join the requested virtual meeting”…The OTP service may subsequently utilize this one-time password seed to obtain an expected ‘one-time password’, which may be utilized to determine whether the provided one-time password from the Participant 602 produces a ‘match’ with this expected one-time password. If so, then the Participant 602 may be ‘authenticated’. The OTP service may transmit a notification to the virtual meeting service 608 indicating whether the Participant 602 has been ‘authenticated’ or not, and if the Participant 602 has been ‘authenticated’, the Virtual Meeting Service 608 may utilize the other provided information to identify a contact method for enabling the participant 602 to join the virtual meeting) [Abstract, col 13, L65 – col 15, L5; Figs. 6, 8 & 10].
As per claim{s} 8, 18, Vu in view of Johansson discloses the recited feature of the method further comprising detecting a disconnection of the moderator device from the collaboration session; and causing the participant device to disconnect from the collaboration session based on detecting the disconnection of the moderator device from the collaboration session (Vu: e.g., At step 435, the content sharing session is ‘terminated’. A content sharing session may be ‘terminated’ by the Miracast® Server. For example, if Moderator client device 120 ‘disconnects’ from the session, the Miracast® server may ‘tear down’ the session {thus causing the rest of the participant devices to ‘terminate their connection’ / disconnect from the session}) [0067, Fig. 4]
As per claim{s} 9, 19, Vu in view of Johansson discloses the recited feature of the method wherein the roster data is received from a server connected to the computing device (Vu: e.g., the ShareCast Server running on Receiver 110 ‘maintains’ a database of the clients ‘connected’ to the ShareCast server for each session. Additionally, any of the clients may query the database and receive the ‘list of clients’ connected to the ShareCast server (e.g., currently ‘participating’ in the session). In response message 735) [0075, Fig. 7]
As per claim{s} 10, 20, Vu in view of Johansson discloses the recited feature of the method further comprising removing, prior to receiving the roster data associated with the first moderator identifier and comprising the plurality of participant identifiers, personal information associated with a moderator and a plurality of participants corresponding, respectively, to the first moderator identifier and the plurality of participant identifiers (Vu: e.g., as it may be desirable for the Moderator to know which ‘member client devices are participating’ in a session, ‘Ms. Wormwood’ {Moderator / teacher} may request, via ‘message’ 725, a ‘list of members’ {Member List / Roster} that have joined the ‘session’. In response to receiving message 725, Receiver 110 transmits to the requestor, Ms. Wormwood, the ‘list of clients’ {Member List / Roster} that have joined the session in message 730. The ‘list of clients’ may include the ‘Session IDs’ of the clients) [0074, Fig. 7] ) (e.g., in accordance with another aspect of the present invention, a moderator client, such as a teacher, may designate a group moderator client device for each group. Moderator client device 120 may then delegate to the group moderator client device some or all of the capabilities of the moderator client device.. The screen of Moderator client device 120 also may display the name or ‘other identification’ of the group Moderator and Non-moderator Member clients in that group {i.e., ‘Session IDs’ of the Moderator and/or member clients} ) [0092].
Conclusion
Applicant’s amendment necessitated the new ground(s) of rejection presented in this Office Action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP 706.06(a). 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 extension fee 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 GLENFORD J MADAMBA whose telephone number is (571)272-7989. The examiner can normally be reached on Mondays to Fridays, 9am-5pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Christopher Parry can be reached on 571-272-8328. The fax phone number for the organization where this application or proceeding is assigned is 703-872-9306.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
/GLENFORD J MADAMBA/Primary Examiner, Art Unit 2451