DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office action is in response to applicant’s amendment filed on 12/09/2025.
Claims 1-5, 7-13 and 15-20 are pending and examined.
Claims 6 and 14 are cancelled.
Response to Arguments
Applicant's arguments filed 12/09/2025 with respect to 35 U.S.C. 101 have been fully considered but they are not persuasive. Applicant argued that claims 1, 9, and 16 have been amended according to the examiner’s recommendation. Examiner would like to clarify that no specific recommendation was given to the applicant with regards to the content or details of the amendments, and only broad suggestions for what type of amendment would be helpful in overcoming a 101 rejection in general were provided to the applicant. The original claim language already specified denying the request, which can be interpreted as preventing conflicting control signals as specified in the amendments. Therefore, the new amendments are further describing the existing limitations and are not sufficient to overcome the 101 rejections. Additionally, there is insufficient detail describing how the amended “preventing” step occurs, and therefore denying the request would be an additional element as “apply it” that is mere instructions to apply an exception. See 35 U.S.C. 101 rejections below for a detailed analysis.
Applicant's arguments filed 12/09/2025 with respect to 35 U.S.C. 103 have been fully considered but they are not persuasive. Applicant argued that the additional features in the amended limitations are neither taught nor suggested by the cited combination. Examiner respectfully disagrees, see 35 U.S.C. 103 rejections below for a detailed analysis. Examiner interprets the previously cited reference of V. Nguyen to disclose the actuator in a process control loop which provides readings as the DCNs including various I/O components such as an actuator which is operated in a process control loop based on the output of sensors correlates to operating an actuator in a process control loop for I/O operations to provide readings. The actuator being operated in a process control group to receive signals from sensors correlates to an actuator in a process control loop receiving control signals. Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Mu with V. Nguyen because actuators on the process automation network can implement a partially automated process with little or no human intervention. These processes can be sub-processes of an overall process where the actuators interface with each other to perform some number of function control blocks or automatically perform a function in response to signals. Cross-platform automation can allow the process automation management system to be implemented on one or more local, cloud or server computing systems for greater flexibility. Additionally, cross-platform process automation can be used in high-cost failure scenarios in terms of human safety and financial cost to stakeholders with backups to provide higher availability or quality of service.
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-5, 7-13 and 15-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to (an) abstract idea(s) without significantly more.
Claims 1, 9, and 16 recite:
receiving, from a cross-platform process automation client, a request to access a writer account of a cross-platform process automation server to write to an input/output (I/O) channel to which access is controlled by the cross-platform process automation server, wherein writing to the I/O channel operates an actuator in a process control loop;
in response to receiving the request to access the writer account of the cross-platform process automation server, determining whether the writer account is available;
in response to determining that the writer account is unavailable, preventing conflicting control signals to the actuator in the process control loop, wherein the preventing comprises denying the request from the cross-platform process automation client to access the writer account of the cross-platform process automation server, and
providing the cross-platform process automation client access to a reader account of the cross-platform process automation server; and
subsequent to providing the cross-platform process automation client access to the reader account, providing one or more readings from the actuator to the cross-platform process automation client.
Step 1: Is the claim to a process, machine, manufacture, or composition of matter?
Yes.
Claim 1 is a process.
Claims 9 and 16 are a system.
Step 2A, Prong I: Does the claim recite an abstract idea, law of nature, or natural phenomenon?
Yes: (an) abstract idea(s).
The ‘determining’ limitation in #2 above, as claimed and under broadest reasonable interpretation (BRI), is a mental process that covers performance of the limitation in the mind. The limitation “determining” in the context of this claim encompasses a person analyzing, evaluating, or determining whether the writer account is available, including comparison or judgement.
Step 2A, Prong II: Does the claim recite additional elements that integrate the judicial exception into a practical application?
No.
The ‘receiving’ limitation in #1 above, as claimed and under broadest reasonable interpretation (BRI), is an additional element that is insignificant extra-solution activity. The limitation “receiving” in the context of this claim encompasses mere data gathering. See MPEP 2106.05(g).
The ‘denying’ limitation in #3 above, as claimed and under broadest reasonable interpretation (BRI), is an additional element as “apply it” that is mere instructions to apply an exception. The limitation “denying” in the context of this claim encompasses merely denying a request to access the writer account. See MPEP 2106.05(f).
The ‘providing’ limitation in #4 above, as claimed and under broadest reasonable interpretation (BRI), is an additional element as “apply it” that is mere instructions to apply an exception. The limitation “providing” in the context of this claim encompasses merely providing access the reader account. See MPEP 2106.05(f).
The ‘providing’ limitation in #5 above, as claimed and under broadest reasonable interpretation (BRI), is an additional element as “apply it” that is mere instructions to apply an exception. The limitation “providing” in the context of this claim encompasses merely one or more readings from the actuator to the client. See MPEP 2106.05(f).
Additionally, one or more of the claims recite the following additional elements:
cross-platform process automation server (Claims 9 and 16)
Input/output channel (Claim 9)
One or more processors (Claim 16)
Memory storing instructions (Claim 16)
These additional elements are recited at a high level of generality (i.e., as generic computer components) such that they amount to no more than components comprising mere instructions to apply the exception. Accordingly, these additional elements do not integrate the abstract idea(s) into a practical application because they do not impose any meaningful limits on practicing the abstract ideas(s).
Step 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception?
No.
As discussed above with respect to integration of the abstract idea(s) into a practical application, the aforementioned additional elements amount to no more than components for obtaining or gathering data and comprising mere instructions to apply the exception which is evidently seen in MPEP 2106.05(g)&(f). Mere instructions to apply an exception using generic computer components cannot provide an inventive concept.
Claims 7 and 15 merely further describe the cross-platform process automation server of Claim 1. The claims do not include additional elements that integrate into practical application or are sufficient to amount to significantly more than the judicial exception.
Claim 8 merely further describes the request to access the writer account of Claim 1. The claim does not include additional elements that integrate into practical application or are sufficient to amount to significantly more than the judicial exception.
Therefore, Claims 1, 7-9, and 15-16 are directed to (an) abstract idea(s) without significantly more.
Claims 2, 10, and 17 recite:
in response to determining that the writer account is available, retrieving login credentials to access the writer account from the cross-platform process automation client; and
authenticating, based on the retrieved login credentials to access the writer account, the cross-platform process automation client to access the writer account of the cross-platform process automation server.
Step 1: Is the claim to a process, machine, manufacture, or composition of matter?
Yes.
Claim 2 is a process.
Claims 10 and 17 are a system.
Step 2A, Prong I: Does the claim recite an abstract idea, law of nature, or natural phenomenon?
Yes: (an) abstract idea(s).
The ‘authenticating’ limitation in #7 above, as claimed and under broadest reasonable interpretation (BRI), is a mental process that covers performance of the limitation in the mind. The limitation “authenticating” in the context of this claim encompasses a person analyzing, evaluating, or determining the authenticity of the retrieved login credentials, including comparison or judgement.
Step 2A, Prong II: Does the claim recite additional elements that integrate the judicial exception into a practical application?
No.
The ‘retrieving’ limitation in #6 above, as claimed and under broadest reasonable interpretation (BRI), is an additional element that is insignificant extra-solution activity. The limitation “retrieving” in the context of this claim encompasses mere data gathering. See MPEP 2106.05(g).
Step 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception?
No.
As discussed above with respect to integration of the abstract idea(s) into a practical application, the aforementioned additional elements amount to no more than components for obtaining or gathering data and comprising mere instructions to apply the exception which is evidently seen in MPEP 2106.05(g)&(f). Mere instructions to apply an exception using generic computer components cannot provide an inventive concept.
Therefore, Claims 2, 10, and 17 are directed to (an) abstract idea(s) without significantly more.
Claims 3, 11, and 18 recite:
detecting a disconnection between the cross-platform process automation client and the writer account of the cross-platform process automation server; and
in response to detecting the disconnection between the cross-platform process automation client and the writer account of the cross-platform process automation server, releasing a writer semaphore so that the writer account becomes available to access for an additional cross-platform process automation client.
Step 1: Is the claim to a process, machine, manufacture, or composition of matter?
Yes.
Claim 3 is a process.
Claims 11 and 18 are a system.
Step 2A, Prong I: Does the claim recite an abstract idea, law of nature, or natural phenomenon?
Yes: (an) abstract idea(s).
The ‘detecting’ limitation in #8 above, as claimed and under broadest reasonable interpretation (BRI), is a mental process that covers performance of the limitation in the mind. The limitation “detecting” in the context of this claim encompasses a person analyzing, evaluating, or determining a disconnection between the client and writer account of the server, including comparison or judgement.
Step 2A, Prong II: Does the claim recite additional elements that integrate the judicial exception into a practical application?
No.
The ‘releasing’ limitation in #9 above, as claimed and under broadest reasonable interpretation (BRI), is an additional element as “apply it” that is mere instructions to apply an exception. The limitation “releasing” in the context of this claim encompasses merely releasing a writer semaphore. See MPEP 2106.05(f).
Step 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception?
No.
As discussed above with respect to integration of the abstract idea(s) into a practical application, the aforementioned additional elements amount to no more than components for obtaining or gathering data and comprising mere instructions to apply the exception which is evidently seen in MPEP 2106.05(f). Mere instructions to apply an exception using generic computer components cannot provide an inventive concept.
Therefore, Claims 3, 11, and 18 are directed to (an) abstract idea(s) without significantly more.
Claims 4, 12, and 19 recite:
receiving, from the cross-platform process automation client, input to be written to the I/O channel; and
writing to the I/O channel based on the input received from the cross-platform process automation client.
Step 1: Is the claim to a process, machine, manufacture, or composition of matter?
Yes.
Claim 4 is a process.
Claims 12 and 19 are a system.
Step 2A, Prong II: Does the claim recite additional elements that integrate the judicial exception into a practical application?
No.
The ‘receiving’ limitation in #10 above, as claimed and under broadest reasonable interpretation (BRI), is an additional element that is insignificant extra-solution activity. The limitation “receiving” in the context of this claim encompasses mere data gathering. See MPEP 2106.05(g).
The ‘writing’ limitation in #11 above, as claimed and under broadest reasonable interpretation (BRI), is an additional element as “apply it” that is mere instructions to apply an exception. The limitation “writing” in the context of this claim encompasses merely writing to the I/O channel. See MPEP 2106.05(f).
Step 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception?
No.
As discussed above with respect to integration of the abstract idea(s) into a practical application, the aforementioned additional elements amount to no more than components for obtaining or gathering data and comprising mere instructions to apply the exception which is evidently seen in MPEP 2106.05(g)&(f). Mere instructions to apply an exception using generic computer components cannot provide an inventive concept.
Therefore, Claims 4, 12, and 19 are directed to (an) abstract idea(s) without significantly more.
Claims 5, 13, and 20 recite:
subscribing the cross-platform process automation client to a writer semaphore to receive a notification when the writer semaphore is released.
Step 1: Is the claim to a process, machine, manufacture, or composition of matter?
Yes.
Claim 5 is a process.
Claims 13 and 20 are a system.
Step 2A, Prong II: Does the claim recite additional elements that integrate the judicial exception into a practical application?
No.
The ‘subscribing’ limitation in #12 above, as claimed and under broadest reasonable interpretation (BRI), is an additional element that is insignificant extra-solution activity. The limitation “subscribing” in the context of this claim encompasses mere data gathering. See MPEP 2106.05(g).
Step 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception?
No.
As discussed above with respect to integration of the abstract idea(s) into a practical application, the aforementioned additional elements amount to no more than components for obtaining or gathering data and comprising mere instructions to apply the exception which is evidently seen in MPEP 2106.05(g). Mere instructions to apply an exception using generic computer components cannot provide an inventive concept.
Therefore, Claims 5, 13, and 20 are directed to (an) abstract idea(s) without significantly more.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, 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, 7, 9 and 15-16 are rejected under 35 U.S.C. 103 as being unpatentable over Mu et al. (U.S. Patent No. US 20200274936 A1), hereinafter “Mu” in view of V. Nguyen et al. (U.S. Patent No. US 20220303338 A1), hereinafter “V. Nguyen.”
With regards to Claim 1, Mu teaches:
A computer-implemented method, comprising:
receiving, from a client, a request to access a writer account of a server to write to an input/output (I/O) channel to which access is controlled by the server (Paragraphs 38, 80 and 82, “Alternatively, the client may submit access requests by issuing packets using block-based access protocols, such as the Small Computer Systems Interface (SCSI) protocol encapsulated over TCP (iSCSI) and SCSI encapsulated over Fibre Channel (FCP), when accessing information in the form of blocks… The initial access request may include the client ID (for interfacing with the network element 310), a request type (read/write), data to be written (for write requests), and a virtual address of requested file N… The disk element 350 receives the initial access request and may perform an access request validation procedure to validate the initial access request (e.g., by determining permission and lock type associated with the client submitting the initial access request)” The access request including the client ID and request type which includes a write request correlates to receiving a request from a client to access a writer account of a server. The access request being submitted by the client through a Fibre channel correlates to receiving a request from a client to write to an I/O channel. The disk element validating the access request correlates to access being controlled by the server);
in response to receiving the request to access the writer account of the server, determining whether the writer account is available (Paragraphs 91-93, “The disk element 350 may validate the access request by locating an entry (“matching entry”) in the disk element session data 802 indexed by the received client ID 810 and file handle 812 combination. The disk element 350 may then analyze the permission flag 815 and lock state type 820 (as found in the matching entry) that is associated with the client ID 810 and file handle 812 combination. By doing so, the disk element 350 may determine whether the received access request is valid (i.e., the user/client 180 has permission to perform the specific access request on the requested file N) … Where two or more clients 180 may simultaneously attempt to write to the same file, the lock state data 820 may be used to determine which client (if any) is permitted to write to the file and to prevent two simultaneous write requests being performed on the same file (which would cause data inconsistency). For example, a first client 180 may be given an exclusive lock state on file N, which is reflected in the lock state data 820 for the first client 180 (as identified by the user ID 805 or client ID 810) in the session data 800.” The disk element validating the access request by analyzing the permission flag and lock state type associated with the client ID correlates to determining whether the writer account is available in response to receiving the request to access the writer account. When no clients currently have write requests, the first client given an exclusive lock state correlates to the writer account being available);
in response to determining that the writer account is unavailable,
preventing conflicting control signals, wherein the preventing comprises denying the request from the client to access the writer account of the server, and
providing the client access to a reader account of the server (Paragraphs 92-93, “Where two or more clients 180 may simultaneously attempt to write to the same file, the lock state data 820 may be used to determine which client (if any) is permitted to write to the file and to prevent two simultaneous write requests being performed on the same file (which would cause data inconsistency). For example, a first client 180 may be given an exclusive lock state on file N, which is reflected in the lock state data 820 for the first client 180 (as identified by the user ID 805 or client ID 810) in the session data 800. As such, a subsequent second client 180 will not be given an exclusive lock state on file N, which is reflected in the lock state data 820 for the second client 180 in the session data 800. If both the first and second clients attempt to perform a write request on file N, the disk element 350 will check the lock state data 820 in the session data 800 to determine which client (if any) is permitted to write to file N. In this example, the disk element 350 will determine that only the first client has the exclusive lock state and is permitted to write to file N, thus preventing two clients from writing to the same file at the same time.” The lock state data indicating that the first client has an exclusive lock state correlates to determining that the writer account is unavailable. The subsequent second client not being given an exclusive lock state, which prevents the second client from write actions but allows read access, correlates to preventing conflicting control signals by denying the request from the client to access the writer account and providing the client access to a reader account of the server); and
subsequent to providing the client access to the reader account, providing one or more readings from the I/O channel to the client (Paragraphs 38, 80 and 84, “Alternatively, the client may submit access requests by issuing packets using block-based access protocols, such as the Small Computer Systems Interface (SCSI) protocol encapsulated over TCP (iSCSI) and SCSI encapsulated over Fibre Channel (FCP), when accessing information in the form of blocks… The initial access request may include the client ID (for interfacing with the network element 310), a request type (read/write), data to be written (for write requests), and a virtual address of requested file N… Using the received user ID and the metadata retrieved from the file inode, the disk element 350 determines whether the received access request is valid (i.e., the user/client 180 has permission to perform the specific access request on the requested file N). If so, the disk element 350 may then perform the received access request on the requested file N (e.g., read data from or write data to file N) that is stored in its associated data aggregate 510.” The disk element determining the access request is valid, which specifies a read type, correlates to authenticating the client to access the reader account of the server. The access request being submitted by the client through a Fibre channel and the disk element performing the received access request such as by reading data from the associated data aggregate correlates to providing one or more readings from the I/O channel to the client).
Mu does not explicitly teach that the client is a cross-platform process automation client, that the server is a cross-platform process automation server, that writing to the I/O channel operates an actuator in a process control loop, that the prevented control signals are to the actuator in the process control loop, and that the I/O channel is an actuator. However, cross-platform process automation clients and servers are a popular type of client and server as evidenced by V. Nguyen (Paragraphs 17, 25 and 53, “Implementations are described herein for commissioning devices to process automation applications and/or systems… In some implementations, process automation management system 102 may be implemented across multiple computer systems as part of what is often referred to as a “cloud infrastructure” or simply the “cloud.” … FIG. 5 is a block diagram of an example computing device 510 that may optionally be utilized to perform one or more aspects of techniques described herein. Computing device 510 typically includes at least one processor 514 which communicates with a number of peripheral devices via bus subsystem 512. These peripheral devices may include a storage subsystem 524, including, for example, a memory subsystem 525 and a file storage subsystem 526, user interface output devices 520, user interface input devices 522, and a network interface subsystem 516. The input and output devices allow user interaction with computing device” The process automation management system implemented across multiple computer systems correlates to a cross-platform process automation server. The computing device including peripheral devices that support user interaction for commissioning devices correlates to cross-platform process automation clients). Additionally, actuators are a popular component in a process control loop for I/O operations as evidenced by V. Nguyen (Paragraphs 19, 27, 33 and claim 1, “One common example of an at least partially automated process is a process loop of a process automation network in which one or more actuators are operated automatically (without human intervention) based on output of one or more sensors. Some at least partially automated processes may be sub-processes of an overall process automation system, such as a single process loop mentioned previously… Each DCN 110 may have various input/output (I/O) components that dictate at least some of its OT capabilities and, more generally, its role at process automation facility 108. For example, first DCN 110.sub.1 includes a flow transmitter (FT) component 114.sub.1 and an actuator (e.g., a valve) 116.sub.1… In some implementations, each DCN may have its own custom profile(s) (e.g., open standard conformance profiles) that convey information about its model, serial number, security level, number and nature of I/O channels such as FT components 114, actuators 116, and/or sensors 118, data formats for each I/O channel, etc… and configuring the DCN to cooperate with one or more of the matched other process automation nodes on the process automation network to implement a process control loop that includes operating at least one actuator of one or more of the matched other process automation nodes based on one or more sensor signals generated by one or more of the matched other process automation nodes.” The DCNs including various I/O components such as an actuator which is operated in a process control loop based on the output of sensors correlates to operating an actuator in a process control loop for I/O operations. The actuator being operated in a process control group to receive signals from sensors correlates to an actuator in a process control loop receiving control signals). Lastly, actuators are a popular type of I/O channel which can provide readings to clients as evidenced by V. Nguyen above (Paragraphs 19, 27, 33 and claim 1).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Mu with wherein writing to the I/O channel operates an actuator in a process control loop, the client being a cross-platform process automation client, the server being a cross-platform process automation server, the prevented control signals are to the actuator in the process control loop, and that the I/O channel is an actuator as taught by V. Nguyen because actuators on the process automation network can implement a partially automated process with little or no human intervention. These processes can be sub-processes of an overall process where the actuators interface with each other to perform some number of function control blocks or automatically perform a function in response to signals. Cross-platform automation can allow the process automation management system to be implemented on one or more local, cloud or server computing systems for greater flexibility. Additionally, cross-platform process automation can be used in high-cost failure scenarios in terms of human safety and financial cost to stakeholders with backups to provide higher availability or quality of service (V. Nguyen: paragraphs 19, 24-26, and 28).
With regards to Claims 9 and 16, the method of Claim 1 performs the same steps as the machines of Claims 9 and 16 respectively, and Claims 9 and 16 are therefore rejected using the same rationale set forth above in the rejection of Claim 1.
With regards to Claim 7, Mu in view of V. Nguyen teaches the method of claim 1 above. V. Nguyen further teaches:
wherein the cross-platform process automation server is hosted by a Distributed Control Node (DCN) that includes one or more additional I/O channels that are in additional to the I/O channel (Paragraphs 25, 30 and 33, “In some implementations, process automation management system 102 may be implemented across multiple computer systems as part of what is often referred to as a “cloud infrastructure” or simply the “cloud.” … Unlike DCNs 110.sub.1-4, DCNN does not include any input/output (actuators or sensors). Instead, DCN.sub.N may be a “compute only” DCN whose role is to facilitate cooperation between itself and one or more other DCNs 110 on process automation network 106 to implement an at least partially automated process… In some implementations, each DCN may have its own custom profile(s) (e.g., open standard conformance profiles) that convey information about its model, serial number, security level, number and nature of I/O channels such as FT components 114, actuators 116, and/or sensors 118, data formats for each I/O channel, etc.” The process automation management system implemented across multiple computer systems correlates to a cross-platform process automation server. The DCNN facilitating cooperation between itself and one or more DCNs on the process automation network to implement the at least partially automated process correlates to the cross-platform process automation server being hosted by a DCN. Each DCN having a number of I/O channels with data formats correlates to a DCN which includes additional I/O channels).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Mu with wherein the cross-platform process automation server is hosted by a Distributed Control Node (DCN) that includes one or more additional I/O channels that are in additional to the I/O channel as taught by V. Nguyen because DCNs can each have custom profiles to convey information about security, sensors, or I/O channels which describe the baseline functionality. These profiles can be used by other nodes in a process automation network to determine which DCNs are compatible with each other (V. Nguyen: paragraph 33).
With regards to Claim 15, the method of Claim 7 performs the same steps as the system of Claim 15, and Claim 15 is therefore rejected using the same rationale set forth above in the rejection of Claim 7.
With regards to Claim 8, Mu in view of V. Nguyen teaches the method of claim 1 above. Mu further teaches:
wherein the request includes login credentials received by the server from the client, to access the writer account of the server (Paragraphs 78 and 80, “For example, to initiate the data-access session with a node, the client 180 may send a connection request to the network element 310. The connection request may contain, for example, a user identification/identifier (ID) and password. Upon authenticating the received client ID and password (e.g., by verifying that the user ID has permission to connect to the cluster 100 and the password is correct), the network element 310 may produce a client ID 810 and send the client ID 810 to the client 180 (which stores the received client ID)… After the connection authentication procedure, the client 180 may then send an initial access request for a particular file (referred to as “requested file N”) in the shared storage 135. The initial access request may include the client ID (for interfacing with the network element 310), a request type (read/write), data to be written (for write requests), and a virtual address of requested file N.” The client sending a connection request containing a user ID and password, and receiving client ID from the server correlates to a login credential. The client then sending the initial access request for writing to the server and including the received client ID correlates to the writer account access request including login credentials received by the server from the client).
Claim(s) 2, 4, 10, 12, 17 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Mu in view of V. Nguyen and Mahaffey et al. (U.S. Patent No. US 9374369 B2), hereinafter “Mahaffey.”
With regards to Claim 2, Mu in view of V. Nguyen teaches the method of claim 1 above. Mu in view of V. Nguyen does not explicitly teach:
in response to determining that the writer account is available, retrieving login credentials to access the writer account from the cross-platform process automation client; and
authenticating, based on the retrieved login credentials to access the writer account, the cross-platform process automation client to access the writer account of the cross-platform process automation server.
However, Mahaffey teaches:
in response to determining that the account is available, retrieving login credentials to access the account from the client (Col. 6, lines 24-32, Col. 8, lines 34-38, 43-48 and Col. 13, lines 10-13 “The system determines if a user is enrolled in a given service with the server. It may do this by retrieving enrollment information from server (e.g. supply hostname or identifier of site as an HTTP referrer or explicitly) or service; looking for presence of a session or authentication cookie; examining the content of user interface for indication that user is logged in; storing a list of enrolled services locally, which may be synced with server periodically… The client may request authorization from server to login or perform action. Example use cases of this embodiment include: login to service, or performing an action on the service (e.g. performing a bank transfer, changing password) … The request may contain information, a service URL or other identifier (e.g. package name, signing key, signing certificate), or an action requested or type of authorization (e.g. login credentials, transfer $1234.33 from account 2912 to “Sally”) … In some embodiments, the authentication server performs authorization of the requesting client to determine what account on the server the client is associated with, and this may happen before performing authorization.” The server periodically examining and performing authorization of the requesting client to determine if the user is logged in correlates to determining that the account is available. The client requesting authorization from the server and entering login credentials after the server authorizes the client and determines which account on the server the client is associated with correlates to retrieving login credentials to access the account in response to determining the account is available); and
authenticating, based on the retrieved login credentials to access the account, the client to access the account of the server (Fig. 2A, Col. 18, lines 8-13 and 21-30, “FIG. 2A is a flow diagram that illustrates client server exchange to validate user credentials, under an embodiment. As shown in diagram 200, the client request 202 comprises information that proves the identity of the client including credentials, such as a token, or username and password, or any of the other authorization objects mentioned above… The client request 202 is processed by the server in a challenge and decision action 204. The challenge utilizes the context of the exchange and the decision is based on authorization based on the credentials provided by the user. In an embodiment, the user authorization is provided by a separate authorizing device or client. Upon valid authorization, the decision by the server allows the client action 206 to be allowed, in which case the user is allowed to enter the website, access the resource, or use the requested service, or other desired action.” The client request which includes login credentials being processed by the server and authorized to allow the client action correlates to authenticating the client to access the account of the server based on retrieved login credentials).
Mahaffey does not explicitly teach that the account is a writer account. However, writer accounts are a popular type of account as evidenced by Mu above (Paragraphs 80 and 82, “The initial access request may include the client ID (for interfacing with the network element 310), a request type (read/write), data to be written (for write requests), and a virtual address of requested file N… The disk element 350 receives the initial access request and may perform an access request validation procedure to validate the initial access request (e.g., by determining permission and lock type associated with the client submitting the initial access request)” The access request including the client ID and request type which includes a write request correlates to a writer account).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Mu with in response to determining that the account is available, retrieving login credentials to access the account from the client; and authenticating, based on the retrieved login credentials to access the account, the client to access the account of the server as taught by Mahaffey because retrieving relevant account information prior to authenticating the account can reduce the number of authentication requests and ensure the client verifies the operation being performed (Mahaffey: Col. 12, lines 53-59 and Col. 13, lines 27-37).
With regards to Claims 10 and 17, the method of Claim 2 performs the same steps as the machines of Claims 10 and 17 respectively, and Claims 10 and 17 are therefore rejected using the same rationale set forth above in the rejection of Claim 2.
With regards to Claim 4, Mu in view of V. Nguyen and Mahaffey teaches the method of claim 2 above. Mu further teaches:
receiving, from the client, input to be written to the I/O channel (Paragraphs 38 and 80, “Alternatively, the client may submit access requests by issuing packets using block-based access protocols, such as the Small Computer Systems Interface (SCSI) protocol encapsulated over TCP (iSCSI) and SCSI encapsulated over Fibre Channel (FCP), when accessing information in the form of blocks… The initial access request may include the client ID (for interfacing with the network element 310), a request type (read/write), data to be written (for write requests), and a virtual address of requested file N.” The access request including the data to be written for write requests correlates to receiving input to be written from the client. The access request being submitted by the client through a Fibre channel correlates to receiving input to be written to an I/O channel from the client);
and writing to the I/O channel based on the input received from the client (Paragraphs 38, 80 and 84, “Alternatively, the client may submit access requests by issuing packets using block-based access protocols, such as the Small Computer Systems Interface (SCSI) protocol encapsulated over TCP (iSCSI) and SCSI encapsulated over Fibre Channel (FCP), when accessing information in the form of blocks… The initial access request may include the client ID (for interfacing with the network element 310), a request type (read/write), data to be written (for write requests), and a virtual address of requested file N… Using the received user ID and the metadata retrieved from the file inode, the disk element 350 determines whether the received access request is valid (i.e., the user/client 180 has permission to perform the specific access request on the requested file N). If so, the disk element 350 may then perform the received access request on the requested file N (e.g., read data from or write data to file N) that is stored in its associated data aggregate 510.” The access request being performed which includes writing the data to be written correlates to writing the input received from the client. The access request being submitted by the client through a Fibre channel correlates to writing the input to an I/O channel).
With regards to Claims 12 and 19, the method of Claim 4 performs the same steps as the machines of Claims 12 and 19 respectively, and Claims 12 and 19 are therefore rejected using the same rationale set forth above in the rejection of Claim 4.
Claim(s) 3, 11 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Mu in view of V. Nguyen, Mahaffey and L. Nguyen et al. (U.S. Patent No. US 9553951 B1), hereinafter “L. Nguyen.”
With regards to Claim 3, Mu in view of V. Nguyen and Mahaffey teaches the method of claim 2 above. Mu further teaches:
detecting a disconnection between the client and the writer account of the server (Paragraphs 94-95, “During a client data-access service, however, the connection between the client 180 and the network element 310 may be dropped/disconnected whether intentionally or unintentionally… In the current network file protocols (such as SMB 2.0 in current Windows® operating systems installed on clients 180), upon a network disconnection, the client 180 is configured to drop/delete the file handle(s) obtained by the client 180 only after a predetermined grace time period after the initial connection failure occurs.” The connection between the client and network element being dropped and a grace time period being calculated after the initial connection failure occurs correlates to detecting a disconnection between the client and the writer account of the server); and
in response to detecting the disconnection between the client and the writer account of the server, releasing a writer lock so that the writer account becomes available to access for an additional client (Paragraphs 93, 97 and 99, “For example, a first client 180 may be given an exclusive lock state on file N, which is reflected in the lock state data 820 for the first client 180 (as identified by the user ID 805 or client ID 810) in the session data 800. As such, a subsequent second client 180 will not be given an exclusive lock state on file N, which is reflected in the lock state data 820 for the second client 180 in the session data 800… In particular, a disconnected client may attempt to reconnect with the partner network element using the previously obtained client ID (referred to as the “original” client ID) and attempt to re-access previously requested files using the file handles (referred to as the “original” file handles) stored to the client 180. The system aggregate 500 associated with the partner node, however, will not have the session data 800 that was collected and stored by the serviced node (which is stored on the system aggregate 500 associated with the serviced node), and thus the partner node will not have access to the session data 800 of the serviced node… Similarly, the partner disk element will not have access to the disk element session data 802 collected by the serviced disk element, which includes original client IDs 810 and original file handles 812 obtained by clients 180 that were previously connected to the serviced disk element, along with permission data 815 and lock state data 820 associated with each client ID 810 and file handle 812 combination.” The system removing session data which includes permission and lock state data for a client after a disconnection correlate to releasing a writer lock in response to a disconnection. The exclusive lock state data being cleared allows new requests to associate a next client ID with an exclusive lock state correlates to the writer account becoming available to access for an additional client).
Mu does not explicitly teach that the writer lock is a writer semaphore. However, semaphores are a popular method of managing access as evidenced by L. Nguyen (Col. 5, lines 42-53, “In one embodiment, an instance S1 of a semaphore mechanism may be created at the request of one client process using one of the interfaces. The creation request may indicate a name (such as a pathname) to be associated with the semaphore instance (e.g., a meaningful name may be selected to indicate the resource being protected), and a maximum number of processes N that may concurrently access the resource R1 to be protected using S1. The maximum number of processes N that may concurrently access the resource R1 protected by the semaphore instance S1 may also be referred to as the “permit count” of S1 herein.” The semaphore associated with a client request for accessing a resource correlate to a writer semaphore).
With regards to Claims 11 and 18, the method of Claim 3 performs the same steps as the machines of Claims 11 and 18 respectively, and Claims 11 and 18 are therefore rejected using the same rationale set forth above in the rejection of Claim 3.
Claim(s) 5, 13 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Mu in view of V. Nguyen and L. Nguyen.
With regards to Claim 5, Mu in view of V. Nguyen teaches the method of claim 1 above. Mu in view of V. Nguyen does not explicitly teach:
subscribing the cross-platform process automation client to a writer semaphore to receive a notification when the writer semaphore is released.
However, L. Nguyen teaches:
subscribing the client to a writer semaphore to receive a notification when the writer semaphore is released (Col. 7, lines 1-20, “The health metric (e.g., how recently the last heartbeat message was received, or how many scheduled heartbeat messages in a row have not been received on time) may for example indicate whether the client process is up and running, or whether the client process is unhealthy or unresponsive (which may be the result of any of various factors such as overload, process exit, or network partitioning). If the communication session is in an unhealthy state, the DSM may, in some such embodiments, remove any permit records of the client process from the registry. This approach may help to ensure that dead or unreachable client processes do not consume semaphore permits indefinitely in such embodiments. In addition, in at least one embodiment, any other client processes waiting to be granted a permit to the semaphore may be automatically notified by the DSM regarding the removal of the permit record associated with the unhealthy session, thus potentially enabling some other client process to obtain access to the resource protected by the semaphore.” The other client processes being automatically notified when the permit semaphore record of the client process is removed correlates to subscribing the client to a writer semaphore to receive a notification when the writer semaphore is released).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Mu with subscribing the client to a writer semaphore to receive a notification when the writer semaphore is released as taught by L. Nguyen because notifying clients when the semaphore permit is removed allows clients that are waiting to be granted the permit to obtain access to the resource. Additionally, periodically checking the client status ensures dead or unreachable clients are not consuming semaphore permits indefinitely (L. Nguyen: Col. 7, lines 1-20).
With regards to Claims 13 and 20, the method of Claim 5 performs the same steps as the machines of Claims 13 and 20 respectively, and Claims 13 and 20 are therefore rejected using the same rationale set forth above in the rejection of Claim 5.
Prior Art Made of Record
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
Gehtman et al. (U.S. Patent No. US 20220358235 A1); teaching a method of access control for protected data using a storage system based multi-factor authentication. The system receives an input/output request for data and initiates an authentication procedure for the user based on the type of request. Certain areas of data may be marked as protected by tags associated with the data and require additional authentication. In response to determining the request is valid, the input/output request is processed by the system.
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.07(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 nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SELINA HU whose telephone number is (571)272-5428. The examiner can normally be reached Monday-Friday 8:30-5:30.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Chat Do can be reached at (571) 272-3721. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/SELINA ELISA HU/Examiner, Art Unit 2193
/Chat C Do/Supervisory Patent Examiner, Art Unit 2193